Build the pipelines on the .NET 10 SDK

[TarasKovalenko]

The release workflow fails before it does anything:

Error: Failed to install dotnet, exit code: 1.
dotnet_install: Error: Could not find `.NET Core SDK` with version = 9.0.0

global.json asks for SDK 9.0.0. That version does not exist and never has — the 9.0 band starts at 9.0.100.

It has been harmless up to now because rollForward quietly lands on whatever 9.0.1xx happens to be installed. actions/setup-dotnet reads the pin literally when you give it a global-json-file, and release.yml gives it one, so the workflow dies at the setup step.

What this does

Rather than correct the pin to a real 9.0 patch, move to 10.0.100 and have both workflows install 10.0.x directly.

The .NET 10 SDK compiles net8.0 and net9.0 too, so one SDK is enough and the 8.0.x / 9.0.x installs come out of every job. The test projects already carry RollForward=Major, so their net9.0 hosts start fine on the .NET 10 runtime and nothing else has to change.

-      # The tool multi-targets net8.0/net9.0/net10.0, so every SDK has to be present.
+      # The .NET 10 SDK builds every framework the tool targets, so one SDK is enough.
       - uses: actions/setup-dotnet@v4
         with:
-          global-json-file: global.json
-          dotnet-version: |
-            8.0.x
-            9.0.x
-            10.0.x
+          dotnet-version: 10.0.x

Verification

Ran on a machine with only the .NET 10 SDK present (10.0.301, 10.0.400), with bin/ and obj/ wiped first so nothing was reused:

dotnet --version              10.0.400
dotnet restore                ok
dotnet build -c Release       Build succeeded, no warnings
dotnet test  -c Release       334 passed, 0 failed
dotnet pack  --no-build       CentralConfigGenerator.2.0.0.nupkg

The package still ships tools/net8.0, tools/net9.0 and tools/net10.0.

Four files, no source changes.