Build solutions with the .NET SDK instead of VS MSBuild

[MrBlue]

The Build Solution step fails on any Windows image whose Visual Studio install does not bundle the .NET SDK. On the Blacksmith windows-2025 image (VS 2022 Build Tools, no .NET SDK component) msbuild.exe has no Microsoft.DotNet.MSBuildSdkResolver, so an SDK-style project cannot be evaluated at all:

src\Oxide.Rust.csproj(3,3): error : Could not resolve SDK "Microsoft.NET.Sdk".
  The NuGetSdkResolver did not resolve this SDK because there was no version specified in the project or global.json.
  MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.NET.Sdk" because directory
  "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Sdks\Microsoft.NET.Sdk\Sdk" did not exist.
src\Oxide.Rust.csproj(3,31): error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.

(Example: Oxide.Rust run 31123440214, which is why the Blacksmith migration in f6fd07c had to be reverted.)

This worked on GitHub's windows-2022 image only because that image ships VS Enterprise with the .NET SDK workload, i.e. the action was implicitly depending on the runner image rather than on anything it installs itself. Instead of patching MSBuildSDKsPath to graft an SDK onto VS MSBuild (fragile, breaks the workload resolver), the action now installs the SDK it needs and drives the build through it:

    - name: Setup .NET SDK
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: ${{ inputs.dotnet-version }}

    - name: Build Solution
      shell: pwsh
      run: dotnet msbuild ${{ inputs.project-name }}.sln -t:rebuild -restore -property:Configuration=... -property:Version=...

dotnet msbuild takes the same targets, properties and -restore semantics as msbuild.exe, and the .NET SDK builds net48 projects on Windows, so the build behaviour is unchanged; microsoft/setup-msbuild is dropped because nothing invokes MSBuild.exe anymore. The SDK version is exposed as an optional dotnet-version input (default 8.0.x) for consumers that need to pin it.

I could not exercise the Windows path from this branch (pushes here don't trigger workflow runs, and game-build.yml only runs from the consuming repos), so the first real validation will be the next Oxide.* build. With this merged, re-applying runs-on: blacksmith-4vcpu-windows-2025 in game-build.yml/project-build.yml should stick.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.}