Upgrades should be tested where applicable during Installation Validation

Description of the new feature/enhancement

I know this will eat compute time so it's fine if it can't happen, but I wonder if upgrades (once they are stable) should be tested in the pipeline. It seems like a lot of users use winget mostly for winget upgrade --all so we should probably make sure that works, especially since the client is going to start telling the user why upgrades aren't working (https://github.com/microsoft/winget-cli/pull/1649). If we could bubble those messages up to the logs and give warnings when upgrades are unsuccessful, it would help a lot! (because maybe we can't avoid upgrade errors because of installer types, but maybe we can?)

Proposed technical implementation details (optional)

Only note I have here is that upgrades should only be tested for installers that don't use vanity URLs (so not Chrome or Spotify). Although those get upgraded sometimes via winget, we can't get the older installers. We can probably figure this out by checking to see if the commit is replacing files or not.

The issue names the Installation Validation pipeline and the winget upgrade --all scenario; start by reviewing how that validation currently installs manifests and records logs. Define which non-vanity-URL installers qualify, then verify unsuccessful upgrades produce warnings and useful log output.