Add a translation option to require a specific version (or version range) for MSVC tool when building on Windows

[PathogenDavid]

Right now generator authors can pin to a specific MSVC tool version or Windows SDK version either by:

• Running their generator from a Visual Studio Developer Command Prompt with a specific -vcvars_ver/-winsdk_version
• Setting the VCToolsInstallDir/WindowsSdkDir environment variables before building the library, IE:

Environment.SetEnvironmentVariable("VCToolsInstallDir", @"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\");

However this is not super intuitive or discoverable, it'd be nice if Biohazrd provided official means of specifying a MSVC tools version preference.

We already do this for the Windows SDK in the private Win32 and DirectX generators, see InfectedWin32.Generator.WindowsSdkHelper.

This would enable a handful of useful features:

• Makes builds more reproducible (minor differences in Windows SDK versions have caused translation churn between my desktop and laptop before.)
• Allows using older MSVC versions when they deprecate/break our version of Clang. (See Upgrade to Clang 12 and resolve forward-compatibility issue with MSVC STL #176 or (Remove) Workaround for STL#1300 intrin0.h issues #98)
• Allows smarter discovery of the MSVC toolchain. (Clang always uses the newest Visual Studio version, including preview versions. If you have 2019 with the C++ workload and 2019 preview without, Clang just fails.)

When we fix this, we should remove the workaround added in #98 and change things to avoid the affected versions and error if they're the only ones available. (Could probably be a warning, but the issue affects most non-trivial libraries and having it be noticeable is probably better than not.)

[PathogenDavid]

For the sake of limiting bus factor, here's WindowsSdkHelper mentioned above: https://gist.github.com/PathogenDavid/29794af32ac1c88fdd489d27a2debb39

It doesn't actually override what Clang uses using environment variables but instead uses --no-standard-includes and -isystem based on the logic Clang uses internally.

Usage looks like this:

// We currently target Windows SDK 10.0.14393.0, which is Windows 10 1607
WindowsSdkHelper sdk = new("10.0.14393.0");
TranslatedLibraryBuilder builder = new()
{
    Options = new TranslationOptions()
    {
        SystemHeadersAreAlwaysOutOfScope = false
    }
};
sdk.ConfigureBuilder(builder);

builder.AddFile(sdk.GetHeaderFilePath("um", "Windows.h"));
builder.AddFile(sdk.GetHeaderFilePath("um", "ShellScalingApi.h"));
// ... etc