Add built-ins for creating/switching cooperative threads

[lukewagner]

This PR extends the concurrency support in Preview 3 with the ability for core wasm to create and switch between "cooperative threads", providing fiber-like functionality that is exposed to core wasm as plain core function imports that are integrated with and built on the async machinery that is already part of Preview 3.

Cooperative threads are meant to be released in some 0.3.x minor version after 0.3.0, so they are given a separate emoji-gate than 0.3.0's 🔀. Since cooperative threads pave the way for preemptive threads (which depend on shared-everything-threads), the emoji-gate for cooperative threads is 🧵 and preemptive threads are switched to 🧵②. The current emoji-gates 🚝 and 🚟 are folded into 🧵 since they're also post-0.3.0 and make sense only with cooperative threads but if there's still a reason to keep them separate, we can split them back out.

This feature is intended to cover both "host threads" (e.g., pthreads.h) and "green threads" (e.g. goroutines and Java virtual threads) use cases. The former use case mostly only needs the ability to spawn a thread (with, in a cooperative setting, the choice between whether to run the new thread immediately or "later"). But the green-threads use case needs to take explicit control of switching between threads (instead of leaving it up to the wasm runtime), so several additional built-ins are added to do this such as thread.switch-to (which works like the switch instruction in the stack-switching proposal). For the summary of the built-ins, see this section. Also see the rewritten goals and summary in Concurrency.md (formerly Async.md).

With the above new built-ins, thread.spawn_indirect becomes an optimized fusion of thread.new_indirect+thread.resume-later. For simplicity, thread.spawn_indirect is kept gated to 🧵②, so that it's "the one that depends on shared" and thread.new_indirect is added by 🧵 and has no shared option for now. As noted in the Binary format TODO, as part of 1.0-rc, we'll need to add a shared? option to every existing built-in (so that they can all be called from preemptive threads) anyhow. But this PR does change the binary format for thread.spawn_indirect (to include an optional shared immediate) so CC @abrown on these changes in Binary.md. (It's fine to not implement them any time soon, but I think it's useful to see the sketch of how they'd eventually look.)

For consistency, the yield built-in is backwards-compatibly renamed thread.yield (keeping the opcode the same and keeping yield in the text format but marked "deprecated" until the transition is done).

What was previously called "context-local storage" in the explainer is now renamed to "thread-local storage" (since it's now literally stored per thread), but the context.{get,set} built-ins keep the same name since they still seem to make sense as names. As planned earlier, the static length of the thread-local storage array is bumped from "1" to "2" b/c now there's a good reason to store the "linear memory shadow stack pointer" alongside the "general TLS struct pointer".

Although a bunch of the explanatory prose changes in this PR, the actual functional addition to what was already necessary for 0.3.0 is surprisingly little; there's mostly just this new ability to directly thread.switch-to. Hopefully that remains true in the implementation.

I expect to keep this PR open for a while until someone with an implementor's hat on has a chance to look carefully, so no rush for folks to review. I'd suggest reading the diff of Concurrency.md first then Explainer.md then CanonicalABI.md.