stringToNewUTF8 moved to library_legacy.js.

[sbc100]

Followup to #19064

All remaining internal usages converted to allocateUTF8. These functions do the same thing and were made into aliases in #19064.

stringToNewUTF8 was added in 443447b and has fewer uses than allocateUTF8.

allocateUTF8 was added in 5174d2e.

[juj]

Originally I created the function pair stringToUTF8 and stringToNewUTF8 as a symmetric API for marshalling a string from JS to already allocated memory area in wasm (e.g. onto stack), or marshalling a string to a new dynamically allocated memory area in wasm (onto heap).

The function name allocateUTF8 felt ambiguous/lacking to me, it read like a malloc function, but it actually not just allocates space for a string, but also copies a string over to wasm as well.

I am not opposed to deprecating stringToNewUTF8 in favor of allocateUTF8 if the new consensus is strongly towards the opposite?

However it will leave the API asymmetric: stringToUTF8 to marshal an existing string over, and allocateUTF8 to dynamically allocate a new UTF8 string to the wasm heap. Is that a non-concern?

In our codebase we do not currently use allocateUTF8 anywhere, but the stringToUTF8 and stringToNewUTF8 pair.

[sbc100]

I'm happy to reverse this and deprecate allocateUTF8 instead. I just think one of them should deprecated, I don't really care which.

[juj]

I think it would seem somewhat off to call stringToNewUTF8 deprecated, but stringToUTF8 not. They feel quite hand in hand?

Would it be beneficial for more symmetry to keep the stringToNewUTF8 and stringToUTF8 pair over allocateUTF8?