Feature request: Component Model support

[glassmonkey]

Problem

wasmtime-go does not currently expose the WebAssembly Component Model.
Embedders who want to load .component.wasm artifacts, call exports
with WIT-typed signatures (records, variants, resources, etc.), or use
WASIp2 from Go have no path forward and have to fall back to other
runtimes or call into the Rust API directly.

#248 left this open with the note that Wasmtime's C API needed to land
first. As of Wasmtime 44, the C API now covers sync/async instantiation,
the full value-type matrix, host functions, resources, type reflection,
WASIp2, and wasi:http — so the prerequisite is met.

Proposed solution

Bind the wasmtime/component/* C API to Go, mirroring the existing
wasmtime-go style (Module, Linker, Instance, Val, ...).

Milestones

The work aligns naturally with the C API's feature flags:

#	Milestone	C API feature flag	What becomes possible
M1	Component Model core	WASMTIME_FEATURE_COMPONENT_MODEL	Load / instantiate components, call exports with the full set of WIT value types, define host functions and resources, reflect over component types
M2	WASIp2 integration	WASMTIME_FEATURE_WASI	WASIp2 components built with tinygo / Rust / etc. run end-to-end from a Go embedder — MVP north star
M3	wasi:http integration	WASMTIME_FEATURE_WASI_HTTP	Components depending on wasi:http run
M4	Async	WASMTIME_FEATURE_COMPONENT_MODEL_ASYNC	Async host functions and async calls are supported

After M2 is reached, M3 and M4 are independent and can progress in
parallel.

Willing to contribute

Yes. If there's interest I can start working towards M1 and open the
first PR for early feedback.

[alexcrichton]

Thanks for the report, and yes indeed the C API should have enough support now to bind things in Go. The wasmtime-py repository has an example embedding of using components. The main tricky questions is going to be component-model-values, but I'm happy to review PRs and work with you if you're interested in pushing on this!

[glassmonkey]

Thanks @alexcrichton for the quick response and for the pointer to wasmtime-py — I'll lean on that as a reference, especially for the component-model-values design where I agree the main complexity lives.

I've already started locally on the smallest meaningful slice of M1: just Component (load / serialize / deserialize / get_export_index), ComponentLinker (instantiate, define_unknown_imports_as_traps, allow_shadowing), and ComponentInstance (get_export_index) — no host functions, no values, no resources yet. It builds and smoke tests pass against components produced inline via Wat2Wasm.

I'll open a draft PR for that slice in the next day or two to start the review conversation. Value-type design and the rest of M1 will come as separate PRs so component-model-values gets its own focused thread.

[glassmonkey]

Followed up with #281 (CI green, marked ready for review). Thanks for the wasmtime-py pointer earlier — useful reference. Feedback welcome at your convenience.

[glassmonkey]

Followed up with #282 (slice 2: type-hierarchy skeleton + test reorganization). CI green, marked ready for review.