Feature request: Component Model support

## 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.