`bindgen!` support for linking component import implementations

#### Feature

Add support through the `bindgen!` macro for adding a component instance to the linker as the backing implementation for a import.

Currently `bindgen!` gives support through `add_to_linker` for specifying an implementation for an import that dispatches to a type that conforms to a trait which matches the import's signature. This feature would add an additional function `add_component_to_linker` which would do the same but instead of dispatching to a trait function implemented on a type, it would instead dispatch to a component instance.

#### Benefit

This has all the benefits associated with WebAssembly itself. Import implementations can be sandboxed so that even untrusted code can be run as an import implementation. This provides an easy way for users of wasmtime to implement "plugin" systems for their import implementations.

#### Implementation

Most likely the `bindgen!` macro would gain the ability to generate a function `add_component_to_linker` function on world structs much like the current `add_to_linker` function.

This function would have the following signature:

```rust
/// Add component as a backing implementation to `linker`
///
/// The component will run against `store` and can have its own imports satisfied by `other_linker`
fn add_component_to_linker(
linker: &mut Linker,
other_linker: &Linker,
other_store: Arc>>,
other_component: &Component,
) -> anyhow::Result<()>;
```

This signature would allow user's complete control over the linked `other_component` including the ability to turn on wasi support or even implement imports for that component. Unfortunately, the implementation needs `other_store` to be `'static` and for it to be possible to get unique references to the underlying `Store`. If we want to allow multiple callers of `add_component_to_linker` to use the same `other_store`, that forces our hand to take `Arc>>`.

The implementation would instantiate `component` against `other_linker` and `other_store` which would be moved inside the wrapped import of `linker`'s root instance. When `linker`'s wrapped import function gets called, the Store's mutex will be locked and the `other_component` instance will be called with the exact same arguments coming from the outer component.

#### Alternatives

The signature for `add_component_to_linker` is a bit awkward (especially due to taking a second linker). This is to maximize the user's ability to control the `other_component` instance. We could simplify the signature at the expense of this user control.

It's also possible for users to implement this without the help of wasmtime or the `bindgen!` macro; it's just fairly finicky code. While it would certainly be helpful for wasmtime to provide this functionality, it does not unlock new use cases that weren't possible before. Therefore, an alternative would be to just not do this.