implement Str.from_utf8/16/32 with lossy variants

[shua]

This change adds the following new functions to the builtin Str module: from_utf8_lossy, from_utf16, from_utf16_lossy, from_utf32, from_utf32_lossy. Only from_utf8_lossy was implemented as a call to zig bitcode, all the rest are implemented as roc code.

I originally implemented them all as zig bitcode, following the existing implementation of from_utf8. I ported it to roc code because it makes for a smaller change, and it feels like a good precedent to implement what I can in roc, and only port it to bitcode as necessary.

There's an issue with the wasm backend where decoding surrogate pairs throws an integer multiplication overflow exception. If I replace the single multiply in the implementation with an equivalent Num.shift_left_by then it panics with integer subtraction overflow exception. I wasn't able to figure out why, so I added a should_panic to the test so it continues to run the test and any magic fixes get flagged as such.

closes #7390

[lukewilliamboswell]

Looks good. Thank you 😃

I think this kind of change would be a perfect candidate for @bhansconnect's https://github.com/bhansconnect/roc-fuzz though we haven't looked at that in a while.

[imclerran]

Ha! Just started writing from_utf16 this afternoon! Guess I don't need to finish that!

[smores56]

In case you didn't notice @shua, you've got failures in your tests. Consider running the following commands suggested by the failing test module:

cargo test -p test_mono -p uitest --no-fail-fast
git add -u
git commit -S -m "update mono tests"
git push origin YOUR_BRANCH_NAME

[shua]

@smores56 Unfortunately, there seems to be some disagreement on mono output between osx aarch64 and every other target. So "fixing" the mono output for one target will break it for the other.

You can see before @lukewilliamboswell 's change, the tests all passed for everything except osx aarch64, after his change only osx aarch64 passes and everything else fails.