JS Text Encoding Builtins

[JS String Builtins](https://github.com/WebAssembly/js-string-builtins) offered great performance improvements for interactions between Wasm and JS strings. However, [de- and encoding was left for a follow-up proposal](https://github.com/WebAssembly/js-string-builtins/blob/81bfc5fb7b8277c6b7d1b0a8f6e57cb31a7bf080/proposals/js-string-builtins/Overview.md#encoding-api). This remains one of the most frequent interactions between Wasm and JS and therefor ripe for performance improvements. To improve performance, many implementations use optimizations to minimize expensive operations. A good example is [Emscripten's implementation of string de/encoding](https://github.com/emscripten-core/emscripten/blob/2760f83517e969fc31e19c3f11b973bfad5f6951/src/lib/libstrings.js#L33-L93). It contains heuristics around small strings that could easily be inconsistent between host machines or engines. Instead it would be highly desirable to move these optimizations to the engine itself. This problem statement is specifically targeted towards languages/toolchains that store their strings in linear memory in UTF-8. Typically, glue code for string de/encoding requires setting up buffers which increases the overhead of every call. So any proposed API has to interact with linear memory directly to reduce that overhead. The ["Future Extensions" sections of the JS String Builtins proposals](https://github.com/WebAssembly/js-string-builtins/blob/81bfc5fb7b8277c6b7d1b0a8f6e57cb31a7bf080/proposals/js-string-builtins/Overview.md#encoding-api) already included an API proposal, however some questions remain: - Can we avoid traps for string lengths that don't fit in a `i32`? (while this can't happen in practice, the specification allows string of that size in theory) - How exactly do we let the API interact with the linear memory? - How do we make the API compatible with Wasm64? - There are still some issues around [`TextDe/Encoder` in worklets](https://github.com/WebAudio/web-audio-api/issues/2499), do we have to account for something here? - Do we want to support de/encoding from/to GC `array`s? We didn't come up with a use-case yet. You can find the full proposal [here](https://hackmd.io/90QpK3FCR0-q1AZQh_udKA).