Don't force shipping versions to be used in VMR builds (#11625)

Don't build MSBuild with shipping versions in the VMR unless the VMR passes an official build ID.

When MSBuild is being built in the VMR, sometimes later-built packages can end up with different versions than earlier-built packages. That's not good, but it doesn't cause failures.

However, these later-built packages can have different (higher) versions of dependency projects that had already been built with the lower versions. This causes downgrade failures like the following intermittently for any VMR jobs triggered around the end of the PST workday:

> Detected package downgrade: Microsoft.Build.Tasks.Core from 17.15.0-ci-25175-01 to centrally defined 17.15.0-ci-25174-01. Update the centrally managed package version to a higher version. 
> Msbuild.Tests.Utilities -> Microsoft.Build.Runtime 17.15.0-ci-25174-01 -> Microsoft.Build.Tasks.Core (>= 17.15.0-ci-25175-01) 
> Msbuild.Tests.Utilities -> Microsoft.Build.Tasks.Core (>= 17.15.0-ci-25174-01)

Author: jkoritzinsky

eng/Versions.props

@@ -6,7 +6,12 @@
     <PackageValidationBaselineVersion>17.14.0-preview-25161-14</PackageValidationBaselineVersion>
     <AssemblyVersion>15.1.0.0</AssemblyVersion>
     <PreReleaseVersionLabel>preview</PreReleaseVersionLabel>
-    <DotNetUseShippingVersions>true</DotNetUseShippingVersions>
+    <!--
+      Don't use shipping versions when building in the VMR unless the VMR directs the build to use shipping versions.
+      This can cause issues when building downstream repos in the orchestrated build if the time MSBuild
+      is built crosses a UTC date boundary.
+    -->
+    <DotNetUseShippingVersions Condition="'$(DotNetBuildOrchestrator)' != 'true'">true</DotNetUseShippingVersions>
     <!-- Workaround for https://github.com/dotnet/roslyn/issues/35793 -->
     <SemanticVersioningV1>true</SemanticVersioningV1>
     <MicroBuildPluginsSwixBuildVersion>1.1.87</MicroBuildPluginsSwixBuildVersion>