Add async support to the component model C API

[chaynabors]

Closes #12955

Adds async equivalents of the component model C API, following the existing core module async patterns in async.h.

New functions:

• wasm_component_model_async
• wasm_component_model_async_builtins
• wasm_component_model_async_stackful
• wasmtime_component_func_call_async
• wasmtime_component_linker_instantiate_async
• wasmtime_component_linker_instance_add_func_async
• wasmtime_component_linker_add_wasip2_async
• wasmtime_component_linker_add_wasi_http_async

A few notes on the design:

• No store-level value storage reuse (unlike core module's wasm_val_storage). The sync component model C API doesn't have it either, so this could be a follow-up for both sync and async.
• C++ header only wraps the WASI/HTTP linker functions since the future-returning functions would need some fort of CallFuture wrapper that doesn't exist for core modules either. Should I add one?
• Feature gated behind component-model-async, enabled by default in release builds. Should this be disabled by default?
• No C API tests for async exist in the codebase today, including for non-component modules. Happy to add some scaffolding if we want it, and have a preference for how it's done.
• I include async.h at the top with the rest of the includes. It's harmless since the file itself is entirely conditional in the interior but the import could be inlined further down. There wasn't any precedence and that gets messy so I didn't.

[alexcrichton]

Thanks for this! Just some minor stylistic comments below, but overall looks great.

There's currently no tests in this PR, and while I realize that we don't currently have tests for async in the C/C++ APIs, would you be up for adding some at least simple tests for calling functions/host functions/etc?

[alexcrichton]

Thanks again for this!

[chaynabors]

@alexcrichton, found a bug with the implementation and resolved it. It appears that the PR is still queued. That feels a little scary from a security perspective so I figured I'd flag? I'm not sure if it's attempting to merge 85dad84 or dec2b79.

Thanks for the nits, I fixed both of them and added tests for module-level and component model async as I'm sure you've already realized. I'll short circuit the ask for tests next time. Thanks for the quick turnaround.

[chaynabors]

Alright, it appears that when I pushed to the branch tests got cancelled and took a bit to propagate. Would make a lot more sense for the approved commit before the push to have been merged otherwise the merge queue is unhermetic?

In any case, checks appear to be bugging out in GitHub, but they pass locally. Sorry for the trouble.

[alexcrichton]

Ah no worries, github merge queues are a bit weird if someone with non-write-access to the repo pushes while it's in the queue, but nothing bad happens it just means that the previous version of the PR is tested/enqueued. The main weird part is that had tests passed this PR would have merged without your updated changes, but that's mostly a github thing.

The tests actually failed due to a completely unrelated spurious failure, but hey worked out!

And yeah sometimes github doesn't actually run PR CI. No idea why, but closing/reopening a PR often fixes that.