Switch to new VMR control schema.

[mmitche]

Now that razor is on .NET 9 arcade, it can switch over to the new control schema. For this repo, this is roughly:

• DotNetBuildFromSource -> DotNetBuildSourceOnly - Building a source-only build.
• DotnetBuildFromSourceFlavor == Product -> DotNetBuildOrchestrator == true - Building in the VMR, could be source-only or MS's build.
• ArcadeBuildFromSource -> DotNetBuildRepo == true -> Indicates an outer repo build.

[jaredpar]

Rather than three diff properties did we consider one propety with three diff values? Like '$(DotNetBuildKind) == 'SourceOnly'`

[mmitche]

Rather than three diff properties did we consider one property with three diff values? Like '$(DotNetBuildKind) == 'SourceOnly'`

We did a bunch of evaluation of this when the control scheme was designed. There are far more than 3 combinations that are interesting, so we ended up with the following general schema:

• There is a property that indicates the exclusive phase of the build, so that you can say that "X should happen only when this code runs in context of Y"
• There are 3 properties that indicates an inclusive phases of the builds. These are "am I running under" type things. So running under the full VMR build (DotNetBuildOrchestrator), vs. isolated repo validation
• DotNetBuildSourceOnly becomes a resource-restriction switch. When it's true, you should only use things that are compatible with source only builds. When it's false you can use anything you might use in an MS build.
• DotNetBuild - Am I running in any flavor of a VMR build (avoids lots of ORs)

The point was to separate out the old DotNetBuildFromSource switch, which was frequently used as both a resource restriction and as an infra switch (how the build works) so that the VMR build could both in MS modes as well as source-only modes.

https://github.com/dotnet/arcade/blob/main/Documentation/UnifiedBuild/Unified-Build-Controls.md has a ton of details around this.