Add .NET 10 support via NativeAOT-LLVM

[JasonAtClockwork]

Description of changes

• Added a dual-path C# module workflow:
  • Stable/default path remains .NET 8
  • Experimental NativeAOT-LLVM path targets .NET 10 behind EXPERIMENTAL_WASM_AOT=1
• Updated the C# runtime packages to switch targets conditionally for the experimental path:
  • SpacetimeDB.Runtime defaults to net8.0 and switches to net10.0 for NativeAOT
  • SpacetimeDB.BSATN.Runtime defaults to netstandard2.1;net8.0 and switches to netstandard2.1;net10.0
• Added a .NET 8-safe shim for WasmImportLinkageAttribute and annotated the NativeAOT host imports that require it
• Reduced the explicit experimental package set to the minimum required:
  • Microsoft.DotNet.ILCompiler.LLVM
  • runtime.$(NETCoreSdkPortableRuntimeIdentifier).Microsoft.DotNet.ILCompiler.LLVM
• Updated the regression-test C# projects to support both paths:
  • default net8.0
  • net10.0 when EXPERIMENTAL_WASM_AOT=1
• Kept the required WASI overlay workaround for NativeAOT-LLVM core-module output:
  • strips .wit files from IlcFrameworkNativePath
  • preserves IlcSdkPath
• Updated spacetime init --native-aot for C# so it injects the full known-good .NET 10 NativeAOT project shape into StdbModule.csproj
• Updated spacetime publish --native-aot so the C# build path:
  • uses the .NET 10 NativeAOT output layout
  • passes the required MSBuild properties for wasm32-unknown-wasip1

Why the heavy changes?

NativeAOT-LLVM currently does not cleanly support the exact output shape we need for SpacetimeDB: a WASI Preview 1/core wasm module that can be hosted by SpacetimeDB/wasmtime today.

In practice, the LLVM/WASI toolchain wants to flow component-model metadata (*.wit) into the link step, which causes linker arguments like --component-type and breaks production of the core module we actually need. The important upstream issue is: [NativeAOT-LLVM] Output non component dotnet/runtimelab#3144

The current workaround is to overlay IlcFrameworkNativePath and exclude *.wit files before LinkNativeLlvm, while preserving IlcSdkPath. Through testing, this was the only project-level workaround that proved necessary; the earlier IlcLlvmTarget property and WasmComponentTypeWit Remove=... item removal were not required once the overlay was in place.

In order to strip out the *.wit files it was necessary to expand the module .csproj to include the following, which will copy out the outputs without the .wit files allowing the build to continue in a core module format:

  <Target Name="UseWasiRuntimeOverlayWithoutComponentWit"
          Condition="'$(EXPERIMENTAL_WASM_AOT)' == '1'"
          AfterTargets="SetupProperties"
          BeforeTargets="LinkNativeLlvm">
    <PropertyGroup>
      <_OriginalIlcSdkPath>$(IlcSdkPath)</_OriginalIlcSdkPath>
      <_WasiRuntimeOverlayDir>$(IntermediateOutputPath)native-hidden-no-wit\</_WasiRuntimeOverlayDir>
    </PropertyGroup>

    <ItemGroup>
      <_WasiRuntimeOverlaySource Include="$(IlcFrameworkNativePath)**\*" Exclude="$(IlcFrameworkNativePath)**\*.wit" />
    </ItemGroup>

    <RemoveDir Directories="$(_WasiRuntimeOverlayDir)" />
    <MakeDir Directories="$(_WasiRuntimeOverlayDir)" />
    <Copy SourceFiles="@(_WasiRuntimeOverlaySource)"
          DestinationFiles="@(_WasiRuntimeOverlaySource->'$(_WasiRuntimeOverlayDir)%(RecursiveDir)%(Filename)%(Extension)')" />

    <PropertyGroup>
      <IlcFrameworkNativePath>$(_WasiRuntimeOverlayDir)</IlcFrameworkNativePath>
      <IlcSdkPath>$(_OriginalIlcSdkPath)</IlcSdkPath>
    </PropertyGroup>
  </Target>

Why .NET 10 And Not .NET 9

I also investigated .NET 9 NativeAOT-LLVM as part of this work, but it is blocked by an upstream MemoryMarshal type-load failure in the NativeAOT-LLVM toolchain:

• browser-wasm - System.TypeLoadException: Could not load type 'System.Runtime.InteropServices.MemoryMarshal' browser-wasm - System.TypeLoadException: Could not load type 'System.Runtime.InteropServices.MemoryMarshal' dotnet/runtimelab#2731

That issue reproduced in our C# module runtime path as well, so this PR keeps the stable path on .NET 8 and targets the experimental NativeAOT path on .NET 10.

API and ABI breaking changes

• Currently breaks .NET 8 NativeAOT-LLVM support by updating references to .NET 10, it might be possible to target both but we'd need more control in the .csproj to disable the .NET 10 specific requirements.

Expected complexity level and risk

2 - The biggest risk is not the stable .NET 8 path, but future changes in the upstream NativeAOT-LLVM/WASI pipeline. This PR intentionally keeps the experimental logic explicit in the generated module project rather than hiding it in transitive package magic, because that proved more reliable during restore/publish testing. We also discussed if we run into troubles due to future changes from the NativeAOT-LLVM branch to pin our version which can be done through the PackageReferences.

Testing

• Ran the C# regression tests on the stable .NET 8 path
• Ran the C# regression tests on the experimental .NET 10 NativeAOT path
• Verified spacetime init --lang csharp --native-aot generates a working StdbModule.csproj
• Verified spacetime publish --native-aot successfully builds and publishes a generated C# project
• Validated the NativeAOT path on both Windows and Linux