Marshal String Encodings

[Aidan63]

details on haxe side : HaxeFoundation/haxe#12476

[tobil4sk]

I think it would be better to include these in the build only if the types are actually needed by haxe. They are more like utilities rather than something that should be a mandatory part of the runtime group.

[Aidan63]

I'll look into it. Another thing I was thinking of was changing string.cpp to use these functions as well since there's a fair bit of duplication here, plus the functions in these classes deal with some things the string.cpp ones don't (various utf-8 ranges are invalid).

I need to check the performance characteristics though, since all these functions are bound checked whereas string.cpp works on raw pointers.

[Aidan63]

I set it up to only be included if used but then remembered that I updated haxe.io.Bytes to use these new classes to avoid issues with needing to trim null terminating characters. Since they're used by a fairly central haxe type and will almost always be included I'm not sure it's worth the extra faff, so I reverted the changes.

I did a bit of benchmarking and converting 10 lorem ipsum paragraphs with some unicode characters from UTF16 to UTF8 100,000 times takes utf8_str 1.2s and cpp.encode.Utf8 2.9s. Some quick profiling showed that bounds checking is not the culprit, but I'll save resolving that difference for another time.

[Aidan63]

I have no idea whats going on with the 4.3 native mac and linux tests, there have been no changes to cpp::Pointer. I can also re-create that failure locally on linux with dev haxe and hxcpp, but the ci on master seem happy...