Allow Hosting Bundle to be upgraded by MU

[wtgodbe]

Adds an .msi, dotnet-hosting-options, which writes to the registry the value of the switches used when last installing the hosting bundle for a given Major.Minor version. Subsequent installs of that band of the hosting bundle will choose what the install in the following way:

• If the user passes any switches on the command line, use exactly those (and write them to the registry, along with 0 for any switches not passed).
• Else use what's in the registry, if there are values in the registry.
• Else set all switches to 0 and write 0 to the registry for each switch

Need to backport this to all servicing branches. In December all customers who get this update thru MU will get a 1-time hit where, regardless of what they already had installed, the hosting bundle will install all components. We suspect most customers install everything anyways, and those who don't will be able to work around this by manually re-running the installer with whatever switches they passed the last time they installed the bundle manually. We should document that in our release notes (CC @rbhanda @danroth27).

6.0: #37967
5.0: #37968
3.1: #37969

Still working on 2.1

[dougbu]

All comments from #37969 apply here

[dougbu]

Side curiosity question: Why did this PR conflict w/ release/6.0 etc.❔

[wtgodbe]

Conflict is due to the format of this ProjectReference in main:

aspnetcore/src/Installers/Windows/WindowsHostingBundle/WindowsHostingBundle.wixproj

Lines 57 to 60 in 15e717a

	<ProjectReference Include="..\SharedFrameworkBundle\SharedFrameworkBundle.wixproj"
	Private="false"
	ReferenceOutputAssembly="false"
	SkipGetTargetFrameworkProperties="true" />

vs 6.0/older:

aspnetcore/src/Installers/Windows/WindowsHostingBundle/WindowsHostingBundle.wixproj

Lines 57 to 60 in ae1a6cb

	<ProjectReference Include="..\SharedFrameworkBundle\SharedFrameworkBundle.wixproj">
	<Private>True</Private>
	<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
	</ProjectReference>

[dougbu]

Conflict is due to the format of this ProjectReference in main:…

Backport #37338 if you like (the GitHub action didn't work for me last I checked ☹️)

[joeloff]

I think you can simplify this further using a preprocessor variable to hold the condition (since it's the same) and then using a foreach to generate a parameterized search, e.g.

<?define Options=OPT_NO_X86;OPT_NO_RUNTIME?>
    <?foreach Option in $(var.Options?>
    <util:RegistrySearch Id="$(var.Option)_should_be_set">
      
    </util:RegistrySearch>
    <?endforeach?>

[joeloff]

Looks good, I left a final suggestion around code clean up to simplify maintenance in the future.

[joeloff]

Delete the conditions since you're generating them through the preprocessor

[danroth27]

We should document that in our release notes (CC @rbhanda @danroth27).

I'm not sure where specifically we should document this. @rbhanda?