Identify start function in CM `thread.spawn` with an index

When designing this proposal's integration with the component model (CM), we decided to pass the start function as a reference to the CM's thread.spawn intrinsic. IIRC, this avoided the issue of forcing the creation of a shared table to contain the start function. But, while doing pathfinding implementation to vet these design choices, I discovered that there are missing pieces in wasm-tools that make this "pass start as a reference" very difficult.

@alexcrichton and @fitzgen can correct me here if I'm not explaining this correctly, but my take is that the implementations in wasm-tools and Wasmtime don't have the necessary plumbing to refer to a CM core type from within a separate CM core module. No other CM intrinsics besides thread.spawn refer to a type declared elsewhere (see $ft here); if we are to pass a reference, we need a type for that reference and that type has an index, but not necessarily the same index, at different stages in the toolchain. @alexcrichton and @fitzgen tell me that adding the necessary index conversions for this new intrinsic in wasm-tools and Wasmtime is too much work; their recommendation is to switch the thread.spawn intrinsic to receive an i32 instead.

At this point, this issue is a roadblock before implementing enough to experiment with different TLS design options, which is what I believe needs more focused attention. The necessary bits are implemented in wasm-tools but this problem of "how to pass the start function" must to be resolved to have a working implementation in Wasmtime. Here are some options to resolve this:

1. figure out some way to implement the missing plumbing between wasm-tools and Wasmtime; @alexcrichton and @fitzgen tell me this is the least desirable choice
2. replace the signature of the CM thread.spawn: [f: (ref null $f) n:i32 c:i32] would become [f: i32 n: i32, c: i32]
3. add an additional CM intrinsic, thread.spawn_indirect, with the new signature [f: i32 n: i32, c: i32]

Note that I am attempting to get this all working in wasi-libc, where one would expect that C function pointers would be placed in a table anyways. It's not clear to me that if we adopted 3 how we might implement the current version of thread.spawn and who would be using it, given how most projects tend to build on top wasi-libc.

Start by reading the Component Model thread.spawn definition and tracing its representation through wasm-tools and Wasmtime, focusing on the core-type and index plumbing described here. Compare the three proposed options against the wasi-libc pathfinding work. Done means a documented design decision that unblocks a working Wasmtime implementation.