Support using previously source-built artifacts in the VMR orchestrator

[ViktorHofer]

Related: dotnet/source-build-reference-packages#1317

There is potential value in providing the ability to build the VMR's msbuild tasks against live references from the previous SB artifacts. This makes it easier to update dependencies like NuGet and MSBuild packages. Today those come from SBRP and require a re-bootstrap to get updated in the VMR product build.

This would also allow to consolidate the infrastructure in BinaryToolKit and other projects that accept a custom versions file: https://github.com/dotnet/dotnet/blob/218225c0da3ed9313aecc9cc13e6b81e2f73c8c8/eng/tools/BinaryToolKit/BinaryToolKit.csproj#L10-L12

[MichaelSimons]

One simple way to get the VMR's msbuild tasks to use the PSB artifacts would be to use the former solution of how SB would lift a product repo's version properties. That is to import the PSB cumulative versions.props file at the end of the VMR's eng/version.props file. I have illustrated this approach in MichaelSimons/dotnet@da0652c.

With this approach the only remaining dependency on the PSB/references is on Microsoft.Build.NoTargets and Microsoft.Build.Traversal (both are text-only packages). I am not sure how to best handle these. Some brainstorming options:

1. Trim PSB/references to just these two packages
2. Promote these two SBRP package to be "normal" PSB packages (Maybe this could apply to all text-only packages)
3. Add Microsoft/MSBuildSdks to SBE in order to build these two packages as "normal" packages

cc @ViktorHofer, @mmitche, @NikolaMilosavljevic, @mthalman.

[MichaelSimons]

There is value in just making the eng/versions.props change as it eliminates the re-bootstrapping pain/blocker when the tasks need to reference a newer package.

[MichaelSimons]

The more I think about this, I am thinking SBRP's text-only packages should be treated as "normal" packages and not as reference packages. Currently the text-only packages are excluded from poison checking which is a strong indicator for this.

If we proceed with this route, a natural question is if text-only packages belong in SBRP. SBE might be a better place for them long term.