Fixes: [AB#2014670](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2014670)
### Description
A change was made in 8.0.2xx to register MSBuildSdkResolver for NGEN (#17732), against both devenv.exe and MSBuild.exe. Later a bug was found in the way MSBuild.exe loads the resolver so the change was reverted in 8.0.3xx (#19112). However, because the change had a measurable positive perf effect, the revert was effectively a regression for devenv.exe and got flagged so by PerfDDRITs.
This PR is a re-do of the original change, only this time with MSBuild.exe omitted, i.e. we're NGENing the resolver only for the default architecture of devenv.exe.
### Customer Impact
Startup perf regression, about 5% more methods JITted in scenarios measured by Visual Studio PerfDDRITs.
### Regression
Yes, perf regression in VS 17.10.
### Risk
Low
We know the minimum and 'bundled' MSbuild versions, but users may build a project with newer SDKs than we expected (specifically when full-framework MSBuild is starting the build of an SDK-style project).
When this occurs, we'd like to automatically condition the use of PackageReferences meant to ensure compatibility of the Roslyn toolchain, so we need to know if we are in this mismatched situation.
A fast and simple way to do this is to 'stamp' the 'expected' version
of MSBuild during product construction and compare that to the
'current' version being used during the actual build.
This reverts commit f0c4e4e14c.
Fixes [AB#1994786](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1994786/)
The MSBuild change which took advantage of this was reverted in 17.9 because it introduced issues in installations that don't have the .NET SDK component installed. We are fixing the bug in 9.0 by making changes to the dependencies of `Microsoft.DotNet.MSBuildSdkResolver` (see https://github.com/dotnet/sdk/pull/39573) so this should stay in main. I am reverting it only in 8.0.3xx / 17.10 to fix the `Build_Ngen_InvalidAssemblyCount` counter which was flagged as a regression by PerfDDRITs.
