[1.8-stable] Fix: DeploymentManager failing with error package downgrade

[guimafelipe]

Replicating #6021

On current telemetry on experimental builds, the majority of the failures on the deployment initialize method is due to ERROR_INSTALL_PACKAGE_DOWNGRADE.

This PR tracks one of the possible ways of that happening in the current code.

When we call GetStatus() (either by itself or inside the Initialize() method), it tries to go over all the packages (Main and Singleton, in that order) and check if they are already installed or not (in the method VerifyPackage()).

The problem is that in the current way this is written, if the Main package is not installed in the machine, but the Singleton package is installed in a higher version, in the for loop, it will verify that Main is not installed and break from the loop. This break will make Singleton package not be verified, and it will not be added to the global map that tracks the versions of the currently installed packages.

Then, on the AddOrRegisterPackages() method in the Deploy stage, we will try to install both packages. But as Singleton was not added to the g_existingTargetPackagesIfHigherVersion map because of the early break, it will attempt to install it when a higher version is already installed.

A microsoft employee must use /azp run to validate using the pipelines below.

WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.

For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

[guimafelipe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).