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.