test(csharp): cover map runtime exports

[yordis]

• Prevents C# Map support from relying on generated bindings alone while the rest of the SDK matrix exercises Map through runtime composition.
• Catches ABI regressions across nested maps, optional values, variants, results, tuples, and byte-list map values.
• Reduces the risk of C# silently diverging from the shared Map ABI as component-model Map support evolves.

[yordis]

Context from debugging this PR:

• C# generated Map bindings compile correctly; map<K, V> lowers to Dictionary<K, V> as expected.
• The failure was in the NativeAOT component metadata path, not in the generated C# Map code.
• The default NativeAOT linker path tries to consume *_component_type.wit through -Wl,--component-type,..., but that parser does not currently handle WIT map<...> syntax.
• The working path in this PR is to let NativeAOT compile the core Wasm, skip its own component metadata step for this fixture, and let the wit-bindgen test harness append Map-aware metadata with wit-component.

I’m planning to follow up separately in dotnet/runtime to investigate the NativeAOT / ILCompiler LLVM component-type parser so -Wl,--component-type,<world>_component_type.wit can handle WIT map<K, V> directly. That would remove the need for this harness workaround long term.

[yordis]

Follow-up notes / order of operations for the native -Wl,--component-type Map path:

• This PR proves C# Map runtime behavior in wit-bindgen by avoiding NativeAOT's current text-WIT componentization path for this fixture and letting the test harness append Map-aware metadata with wit-component.
• The native -Wl,--component-type,<world>_component_type.wit path still depends on the WASI SDK linker toolchain understanding map<K, V> directly.
• The relevant source chain is:
  1. bytecodealliance/wasm-tools / wit-parser / wit-component need Map support.
  2. bytecodealliance/wasm-component-ld must depend on that Map-capable wasm-tools stack.
  3. WebAssembly/wasi-sdk must package that newer wasm-component-ld.
  4. dotnet/runtimelab must bump its WASI SDK pin for Microsoft.DotNet.ILCompiler.LLVM.
• Current investigation found dotnet/runtimelab's feature/NativeAOT-LLVM branch pins WASI SDK 29, and WASI SDK 29 packages wasm-component-ld 0.5.19. The local wasm-component-ld checkout is already at 0.5.25 with wit-parser / wit-component 0.252.0, which is the direction needed for native Map parsing.

My next follow-up outside this PR is to validate the newest wasm-component-ld against a minimal map<K, V> component-type WIT, then work forward through the WASI SDK / runtimelab pin chain if that succeeds.

[yordis]

Follow-up correction on the external toolchain thread:

• I opened bytecodealliance/wasm-component-ld PR Rename *.wai to *.wit #107 as an exploratory regression test for --component-type with WIT map<K, V>: Add map component type regression test wasm-component-ld#107
• After talking to @alexcrichton, we decided to close that PR for now: Add map component type regression test wasm-component-ld#107 (comment)
• So the wasm-component-ld PR should not be treated as an active follow-up path from this PR.
• The useful takeaway remains that newer wasm-component-ld / wasm-tools already has the Map-capable parser stack; the longer-term NativeAOT -Wl,--component-type path is still a packaging/toolchain adoption question across WASI SDK and runtimelab, not something this wit-bindgen PR needs to solve.

For this PR, the intended scope remains the working wit-bindgen-side bridge: NativeAOT compiles the C# Wasm, and the test harness appends Map-aware component metadata with wit-component.

[yordis]

Additional follow-up status on the WASI SDK side:

• WASI SDK main already pins wasm-component-ld 0.5.26.
• The latest release candidate I checked, wasi-sdk-34-rc.1, still pins wasm-component-ld 0.5.24.
• Older releases lag further behind: wasi-sdk-33 uses 0.5.22, wasi-sdk-30 uses 0.5.20, and wasi-sdk-29 uses 0.5.19.

So the next external step does not look like a WASI SDK code PR right now; main already has the newer linker. The remaining question is release/consumption: either wait for a WASI SDK release that includes the 0.5.26 bump, or decide whether dotnet/runtimelab should consume a specific unreleased WASI SDK commit/build.