Ensure non-final builds have unique package GUIDs

[JunTaoLuo]

This addresses dotnet/installer#2655

The regression seems to be 41ce223#diff-8a63ea279503159f0bb870af84feae00L10. I'm assuming it was an oversight when removing the BuildNumberSuffix variable. I'm updating the logic to mimic the previous behaviour, albeit using different variables.

I've verified with this change that the product code and upgrade code are now unique between builds. However, I don't think I'll be able to do end to end verification.

I plan on merging as soon as builds are green, so the change can be consumed downstream.

cc @johnbeisner

[johnbeisner]

@JunTaoLuo
Why would the final builds need a stable GUID, release over release. I would think we would have the same problem. I don't think we should block on this, but we should have a discussion on what the expected behaviors that we want to see from our combined installers.

[JunTaoLuo]

Yea, I wasn't sure why but this is the behaviour I see in our previous code. Since I couldn't track down why it was built that way, I figured it's safer to keep it until I can find out more.

[JunTaoLuo]

Do you know what's the logic used by other teams? @johnbeisner

[johnbeisner]

For dotnet/core-sdk MSIs:

<GenerateGuidFromName Name="$(SdkMSIInstallerFile)">
      <Output TaskParameter="OutputGuid"

Where the seed string 'SdkMSIInstallerFile' for the MSI GUID is full path + filename: "C:\buildrootcoresdk\artifacts\packages\Release\Shipping\dotnet-sdk-3.0.100-preview7-012608-win-x64.msi"

[JunTaoLuo]

Ah, then I think we should follow suite.

[joeloff]

The logic got removed as part of the arcade work it seems: 41ce223#diff-8a63ea279503159f0bb870af84feae00