c-api: Create and instantiate a component model linker

[MangoPeachGrape]

Next small chunk of #9812.

I'm not sure about the lifetime requirements of wasmtime_component_linker_instance(), is there any better way to express this?
See previous discussion: #9812 (comment)

[alexcrichton]

Thanks! Would you be up for additionally writing tests now that we've got that set up? Ideally through a new C++ API but also optionally through the C API.

[MangoPeachGrape]

Yes! I would like to write tests, but I'm not sure on some things:

I tested this locally by writing an "example" host using these functions, and running it with a guest component which doesn't import anything.
How would this be represented as a test in the repo?
Would this kind of E2E test go into the c-api/tests?
How would the guest component get compiled?

Also, I'm not sure if I would want to update the C++ API as well in these PRs. Would it make more sense to add tests for the C API now, and if later - when the same functionality gets exposed to C++ API, and a test written for it - made the C test obsolete, remove it?

[alexcrichton]

My thinking is that most of the tests could use the text format of WebAssembly, meaning the test wasm file would be in-line with the test itself (this is used a lot on the Rust side for testing too). Orchestrating native-language binaries compiled to wasm to be available in the tests is possible but will be a bit of a pain.

For location, yeah I'm thinking we'd drop things in crates/c-api/tests/*.cc. And yeah if you'd prefer to start by testing the C API I think that's reasonable.

[MangoPeachGrape]

@alexcrichton What do you want in the next PR?

[alexcrichton]

How about sketching out the Linker API? Basically being able to create recursive instances/etc. Perhaps hooking up the wasmtime_module_t type where you can supply a core module to a component? (in lieu of defining functions which I think is a bit harder to do as a single step)

My main concern there is that the Linker API in Rust has a lot of borrowed lifetimes which makes it nontrivial to map to other languages. Clear ownership semantics tend to work out best IMO, and it's also the case that performance is not of the utmost concern when creating a Linker. In that sense I think we may want to design this in such a way such that separate pointers in the C API aren't intrinsically linked but instead perhaps define an item-at-a-time where there's no intermediately-owned structures?

One example could be that the entire "path" to an item is passed to the C API, where each element in the path is an exported instance layer. That would then call .instance(..) as necessary in the Rust API and define the requested item at the leaf when the path is iterated over. Or... something like that, just some vague ideas.

It's not that we can't have inter-related objects in the C API, it's mostly just that I'd prefer to avoid it if possible.