Add Installer project build skip functionality for servicing builds

[dagood]

This ports servicing build infrastructure from Core-Setup 3.1 (https://github.com/dotnet/core-setup/issues/8735) that disables certain Installer projects as needed during product servicing.

I'm including a fix to make it work as expected for prerelease servicing releases, so details from #639 (comment) describe this particular implementation:

I think the right fix is [to have the settings apply unconditionally]

-  <ItemGroup Condition="'$(StabilizePackageVersion)' == 'true'">
+  <ItemGroup>
     <ProjectServicingConfiguration Include="Microsoft.NETCore.App.Ref" PatchVersion="0" />
     <ProjectServicingConfiguration Include="NETStandard.Library.Ref" PatchVersion="0" />
   </ItemGroup>

With this:

• During master builds, patch version for Microsoft.NETCore.App is always 0, so it gets built.
• When release/5.0 forks, patch stays 0, so it keeps getting built.
  • After releasing 5.0.0, version advances to 5.0.1, and optionally becomes 5.0.1-servicing-12345. This disables the targeting pack build due to the patch version not matching, as desired.
  • Enabling it is same as always, set PatchVersion="1" to make it match

This PR isn't intended to change the current build outputs at all.

I tested by increasing the PatchVersion prop and seeing the expected artifacts stop building. This was tested more back with dotnet/arcade#4318.

/cc @mmitche @nguerrera @dotnet/runtime-infrastructure

[dagood]

The "runtime (Libraries Test Run release mono Linux x64 Debug)" failures are unrelated and being worked on, merging through. #2316

[NikolaMilosavljevic]

Is this property not needed anymore? Was '0' used to specify patch version?

[dagood]

It's needed, but it's calculated in the following target, so this is a minor refactor to improve clarity:

runtime/src/installer/Directory.Build.targets

Lines 29 to 46 in 9a8f52c

	<!--
	Arcade SDK versioning is defined by static properties in a targets file: work around this by
	moving properties based on versioning into a target.
	-->
	<Target Name="GetProductVersions">
	<PropertyGroup>
	<IncludePreReleaseLabelInPackageVersion Condition="'$(DotNetFinalVersionKind)' != 'release'">true</IncludePreReleaseLabelInPackageVersion>
	<IncludePreReleaseLabelInPackageVersion Condition="'$(SuppressFinalPackageVersion)' == 'true'">true</IncludePreReleaseLabelInPackageVersion>
	<IncludePreReleaseLabelInPackageVersion Condition="'$(IsShipping)' != 'true'">true</IncludePreReleaseLabelInPackageVersion>
	<IncludeBuildNumberInPackageVersion Condition="'$(StabilizePackageVersion)' != 'true'">true</IncludeBuildNumberInPackageVersion>
	<IncludeBuildNumberInPackageVersion Condition="'$(SuppressFinalPackageVersion)' == 'true'">true</IncludeBuildNumberInPackageVersion>
	<IncludeBuildNumberInPackageVersion Condition="'$(IsShipping)' != 'true'">true</IncludeBuildNumberInPackageVersion>
	<ProductVersionSuffix Condition="'$(IncludePreReleaseLabelInPackageVersion)' == 'true'">-$(VersionSuffix)</ProductVersionSuffix>
	<ProductBandVersion Condition="'$(ProductBandVersion)' == ''">$(MajorVersion).$(MinorVersion)</ProductBandVersion>
	<ProductionVersion Condition="'$(ProductionVersion)' == ''">$(ProductBandVersion).$(PatchVersion)</ProductionVersion>
	<ProductVersion>$(ProductionVersion)$(ProductVersionSuffix)</ProductVersion>

Yeah, .0 here was just the old, hard-to-find way the patch version was defined. Putting it in eng/Version.props makes it easier to rev versions to service the repo.