As part of the planned switchover from Crossgen to Crossgen2 we need to gradually enable Crossgen2 in various parts of our build system. As a first step I believe we should generalize System.Private.CoreLib crossgenning logic to optionally support Crossgen2. As part of this task I'm trying to reduce the duplication in the scripts src/coreclr/crossgen-corelib.cmd / sh by moving most of the build logic into the common project crossgen-corelib.proj.

In my initial local change in this direction I hit the usual problem with setup_vs_tools that is needed on Windows to add paths to a VS installation that are used to search for the PDB native library Microsoft.DiaSymReader.Native.amd64.dll. I'm wondering what is the cleanest way of fixing this:

1. Should we run something like setup_vs_tools at the very beginning i.e. when descending from the build.cmd root script to build.ps1?

2. A relatively conservative way I could approach this now is by changing crossgen-corelib.cmd / sh scripts (that today contain the bulk of the actual work) to thin wrappers, just calling setup_vs_tools on Windows and running the proj script. The downside is that this doesn't solve the descent from eng/Subsets.props to src/coreclr/crossgen-corelib.proj, that still needs a separate solution.

3. Do we actually need / is it the cleanest approach to require VS installation for the presence of the Microsoft.DiaSymReader.Native.amd64.dll library? @tmat, could we consume the library via some Nuget feed instead?

/cc: @dotnet/runtime-infrastructure
/cc: @dotnet/crossgen-contrib

RFC: @jkoritzinsky, @ViktorHofer, @safern, @jkotas