Compatible with JS String Builtin proposal

[oovm]

The JS String Builtin provides a set of functions to the wasm:js-string namespace, and it is best to wit them to fit into the component model system.

1. Standardize unmanaged core module imports in the wasm:js-string namespace
2. Host can selectively implement some js functions
3. Linker can select the required shim implementation
4. As a shared core definition, other js binding libraries can import and pass js strings without loss

There are many details to discuss, such as

• wasm:js-string is not a valid world name
• Is js-string a resource?

[lukewagner]

Taking a step back, the JS String built-ins are primarily an optimization useful for languages targeting wasm-gc, mainly, Kotlin, Dart and the subset of Java supported by J2CL. Although it's definitely a goal to support wasm-gc in the component-model's Canonical ABI, it hasn't been added yet, so it wouldn't yet be an optimization compared to what could be done with normal string + resource types.

Once we do integrate wasm-gc with the Canonical ABI, though, I think it would make sense to add a new string-encoding Canonical ABI option that lowers values of the string WIT type into a core wasm externref that comes with a new set of Canonical ABI built-ins in the same spirit as the JS String Builtins. Importantly, though, in the language- and host-agnostic context of the component-model, I think we need to be more conservative than the JS String Builtins proposal in the set of built-in operations provided since we can't assume, like the JS String Builtins proposal can, that we're working with a JS string. In particular, we'd want to avoid adding operations like random-access to WTF-16 16-bit code units, concatentation operations that require the rope optimization to achieve O(1) and the extensible string optimization to achieve amortized O(n) in copy loops, substring operations that require the dependent string optimization to achieve O(1) (at the cost of GC pressure), etc. So we'd probably have something a bit more spartan that ensured, e.g., that host-UTF-8 strings would have the same algorithmic complexity as host-UTF-16.

The neat thing about this approach is that WASI interfaces wouldn't have to pick a string representation; they could keep using string and then the implementation language gets to opt in to the new GC-friendly string representation as an ABI choice.