Cache NativeAOT Visual Studio tool discovery

[MichalStrehovsky]

Fixes #129265

Run vswhere during Windows NativeAOT setup to validate the selected Visual Studio installation and reuse cached vcvarsall output when the installation path and version match.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR updates the Windows NativeAOT build integration to discover Visual Studio toolchains via vswhere.exe and cache the derived vcvarsall.bat output (tool directory + LIB paths) in $(NativeIntermediateOutputPath) so subsequent builds can reuse it.

Changes:

• Replace the findvcvarsall.bat invocation with in-target vswhere.exe calls to locate the VS installation path/version and compute the appropriate vcvarsall environment.
• Add a per-architecture cache file (findvcvarsall.$(_targetArchitecture).txt) to reuse prior vcvarsall output when the VS path/version match.
• Remove the now-unused findvcvarsall.bat script.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Windows.targets	Implements vswhere-based VS discovery and a cache file to reuse vcvarsall output.
src/coreclr/nativeaot/BuildIntegration/findvcvarsall.bat	Deleted (logic is now embedded in the .targets file).

[MichalStrehovsky]

@eduardo-vp could you have a look at this? it basically inlines the findvcvarsall into MSBuild and introduces caching.

Before this change, we were guaranteed to spend a second of the build in findvcvarsall, even in incremental do nothing scenarios. Now incremental builds take ~100 ms (running vswhere takes ~50 ms by itself and we run it twice).

[eduardo-vp]

LGTM!

[MichalStrehovsky]

/ba-g arm64 Windows helix is known to be dead