Wrap component function exports in functions that call __wasilibc_init_task

[TartanLlama]

Exports need their stack pointer and thread-local storage set up. For this, in wasip3, wasi-libc can export __wasilibc_init_task(_async) functions that should be called before the real component exports are called. This PR introduces a new module into components generated by wit-component when it detects __wasilibc_init_task(_async) functions exported from the main module.

This new module is called wasilibc-init-wrappers. For every function the component exports, it imports that function, and exports a wrapper that calls the relevant task initialization function before calling the original export. I did this with a separate module to cleanly separate out the logic, but could dump the wrappers into the original module or the shim if desired.

[alexcrichton]

Thanks!

Some high level thoughts on this:

• With non-wasi-libc languages (e.g. Go) I think we'll rpobably want to drop the wasilibc part of the symbol names here, but having __init_task and __init_async_task (or something like that) seems reasonable to me.
• Long-term I think we'll want to avoid the need to create an extra module here. That has code size and inlining implications in wasm runtimes and this will, by default, affect all exports for WASIp3+ components. Given that impact I think eventually we'll want to inject these wrappers in the original module rather than in an auxiliary module. In the meantime, however, that's a fair bit of infrastructure not already in wit-component so I don't want to put that on you here. Instead wanted to confirm you feel this is a reasonable path (eventually) and then we can file an issue about it.
• For testing this you can add a component/core module to crates/wit-component/tests/components and that has various WIT/WAT/etc files to combine to ensure this has at least smoke tests for the produced module.

[TartanLlama]

I think we'll probably want to drop the wasilibc part of the symbol names here

Sure, maybe worth keeping a wasm prefix or something? And I think ideally, when we have the design for all of this stuff more fully fleshed out, I'd like to have all of these symbols documented as part of the BuildTargets or some general toolchain ABI document.

Long-term I think we'll want to avoid the need to create an extra module here

Yeah, that sounds good to me.

For testing this you can add a component/core module to crates/wit-component/tests/components and that has various WIT/WAT/etc files to combine to ensure this has at least smoke tests for the produced module.

👍

[alexcrichton]

On one hand that seems redundant to have a wasm prefix (everything is wasm after all) but on the other hand it doesn't hurt to be explicit. Basically I could go either way myself, happy to defer to your judgement