[coop-threading] Track concurrent state for synchronous calls

[TartanLlama]

Threads are currently not created on sync->sync export calls, sync host->guest calls, and module-level start function calls. This PR adds support to this for all of these.

I added a component-model-async feature to wasmtime-environ so that sync->sync adapters are compiled as they were originally for wasip2 code, avoiding changing performance characteristics.

Rather than use the existing prepare_call + start_call machinery, I introduced sync_to_sync_enter/exit_call intrinsics to avoid adding additional host frames to the stack for sync calls.

Currently, doing operations that require thread state inside post_return functions is unsupported. If we're happy merging this as-is and creating an issue to resolve this later, we can do so, or I can try and address it prior to merging.

Fixes #11954

[dicej]

I've only skimmed this so far; it looks generally reasonable, but I expect it will conflict with #12153, which I'm about to split into smaller PRs per @alexcrichton's request.

Given that the component-model-async feature is now enabled by default, we'll need to be conscious of the overhead of e.g. calling sync_to_sync_enter_call and sync_to_sync_exit_call per this Zulip topic. In #12153, I had to get creative and sometimes lazily push GuestTasks and GuestThreads as necessary to avoid pessimizing sync-to-sync adapters. @TartanLlama we should chat sometime about if (and if so, how) we could do a similar optimization here.

[dicej]

See #12311 for the latest plan. I'm planning to work on a new PR tomorrow that ensures we always push a task and thread on the stack when entering Wasm from the guest or host, at which point we can rebase this PR on top of that.

[alexcrichton]

@dicej / @TartanLlama does #12379 subsume this? (my impression is "yes" but want to confirm)

[TartanLlama]

Yeah I believe it is. Closing for now, can always grab stuff from the branch if we need it