Include `ProductCode` in the winget manifest

`winget` is requiring us to include `ProductCode` of the MSIs in `Microsoft.AzureCLI`'s manifest (https://github.com/microsoft/winget-pkgs/pull/123641#issuecomment-1778044560): https://github.com/microsoft/winget-pkgs/blob/master/manifests/m/Microsoft/AzureCLI/2.54.0/Microsoft.AzureCLI.installer.yaml

Three methods for extracting the `ProductCode` are provided: https://github.com/microsoft/winget-pkgs/pull/123641#discussion_r1371447095

> If you use one of the popular [manifest authoring tools](https://github.com/microsoft/winget-pkgs#authoring-a-manifest) to create the manifest, they will automatically add/update this field for you.
>
> If you want to retrieve this for yourself, you can use a number of different methods:
>
> * For installed MSI packages, you can get it by running the command (On PowerShell 5 / Windows PowerShell)
> ```
> get-wmiobject Win32_Product | Sort-Object Name | Format-Table IdentifyingNumber, Name -AutoSize
> ```
> * If you have the `.msi` file, you can use something like [MSI Viewer](https://apps.microsoft.com/detail/msi-viewer/9MZTR9QS01GN) or some PowerShell scripting to retrieve the ProductCode.
> * You can run the [manifest in Windows Sandbox using the sandbox script](https://github.com/microsoft/winget-pkgs#in-windows-sandbox) and it will print out the related metadata for the package which includes the ProductCode

I am able to get the `ProductCode` with the first method on my Windows machine (even though `Get-WmiObject Win32_Product` is slow):

```
> Get-WmiObject Win32_Product | Sort-Object Name | Format-Table IdentifyingNumber, Name, Version -AutoSize

IdentifyingNumber Name Version
----------------- ---- -------
...
{C56C2883-5C38-4789-B6BA-4D4B17440AE6} Microsoft Azure CLI (64-bit) 2.54.0
```

However, all these methods require either installing the MSI or other dependencies. As our automation bot @azclibot for generating the manifest is hosted on a Linux agent and the manifest generation logic is written in Bash syntax, these methods may not be practicable unless we move @azclibot to a Windows agent.

A workaround I can think of is to extract the `ProductCode` while building the MSI and save it to the built ADO artifact. Then use the `ProductCode` saved in the artifact to generate the manifest.

---

**Regarding a fixed `ProductCode`**

According to https://wixtoolset.org/docs/v3/xsd/wix/product/, `Id` of `Product` element is an `AutogenGuid`:

> The product code GUID for the product.

So, in Azure CLI's `Product.wxs`, it is declared as

https://github.com/Azure/azure-cli/blob/aeb94ed12a46acdd14e7c4e2633908e149f4a1bc/build_scripts/windows/Product.wxs#L36

And according to https://learn.microsoft.com/en-us/windows/win32/msi/productcode

> This ID must vary for different versions and languages.

It is not possible to have a fixed GUID. We must generate a new one for each MSI package.

Also see:

- https://stackoverflow.com/questions/26734030/is-it-necessary-to-use-unique-wix-product-id-for-all-product-versions-if-upgrade