Remove utf8-cstr binding

[jgravelle-google]

It's overfitted to C, and causes more confusion than it adds clarity.

If this puts undue burden on C strings, we can re-add this binding post-mvp

[dcodeIO]

It seems that the length (end) of the buffer will have to be computed at some point anyway. So, with the binding, that'd be up to the host, while without the binding (as proposed here), that'd be up to the module. In the unlikely but possible case that the module knows the length beforehand, it could pass that to the host so it doesn't have to compute it again, while if it doesn't, the module can as well compute (and potentially cache) it in WASM efficiently. Remains the question what the binding will do when a target requires a zero-terminated string, so some sort of indicator would be necessary here.

Not sure how well this fits with the UTF-16LE issue, but that might just be a variant UTF-8-zero-terminated as I proposed there, leaving us with:

1. Both UTF-8 or UTF-8-zero-terminated: Essentially memcpy
2. One UTF-8, one UTF-8-zero-terminated: Essentially memcpy +/- 0
3. One UTF-8(-zero-terminated), one something else: Re-encode once

[jgravelle-google]

Amusingly the cstr binding would necessarily defer the strlen call to the host, and therefore always have that O(n) scan, whereas leaving it in userspace lets the caller actually cache it. I predict that in practice C++ will use std::strings and thus store the length on the struct itself.

Fun fact my original idea behind cstr was to move the call out of userland entirely, and when performing share-nothing linking between two C modules, the host could observe a cstr on either side and opportunistically elide the copy entirely. This turns out to not work because that requires sharing of memory, which is something we want to not need in that scheme, making a cstr binding much more useless.

[lukewagner]

Yes, let's not let people be distracted by this.