When generating MSIs, use heat.exe "-ag", not "-gg" to make component GUIDs more stable

[dagood]

Right now, we use heat.exe -gg rather than -ag:

https://github.com/dotnet/arcade/blob/cb840a9bb99335f80024ea04816e7799461879cc/src/Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk/targets/windows/wix.targets#L218-L223

This is also the case in earlier servicing branches, and in core-sdk.

-gg essentially generates random GUIDs, but -ag makes them repeatable based on target path. (From "heat ag vs gg" and advice from @joeloff.)

Having random componetn GUIDs is normally not a problem in our specific scenario, because these MSIs are never intended to install to the same locations on disk. (AKA the MSIs are installed side-by-side, and have no shared components.)

But the 3.1.0 issues ended up with us releasing two versions of our MSIs that do install to the same locations on disk. This causes problems when trying to switch between those two MSIs. (We don't yet know the exact situation, but it's well-known issue that comes up when the MSI authoring has this mistake.)

The problems with 3.1.0 should be solved by running a Repair, and will not be a problem in 3.1.1 as long as we don't make the same mistakes as 3.1.0.

(The Host MSIs do install shared components, however they doesn't have the same authoring issue.)

[dagood]

I realized that A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.0'. only shows up when you are trying to use the SDK, not just the dotnet host with the Runtime installed. From there, I got a repro:

1. Install the 3.1.100 SDK
2. Install the 3.1.0 hosting bundle
3. Uninstall the hosting bundle's x64 runtime (bad one, branded (but not actually) "Preview 3")
4. Install the fixed x64 runtime bundle (.NET Desktop runtime bundle)

The only thing left in my shared/Microsoft.NETCore.App/3.1.0 dir is mscordaccore_amd64_amd64_4.700.19.56402.dll after that, which makes sense given the bad GUIDs, and causes this break.

Running Repair on the fixed x64 runtime bundle (right click in Add/Remove Programs => Modify => Repair) puts all the files back and commands start working.

[NikolaMilosavljevic]

Fix needed to avoid issue seen with 3.1.0 release.