Add -UpdatePackages support for App and Flight Submissions

[HowardWolosky]

Currently we have -AddPackages which will simply append the packages from the StoreBroker payload to the cloned submission, and we have -ReplacePackages which will remove all current packages and only keep the ones within the StoreBroker payload.

The Store apparently has a maximum limit of 30 packages for any submission, and some teams that flight frequently hit this limit more than once per month, which has required manual intervention via the Dev Portal. Generally, most of those packages are redundant, meaning that they'll never be given to the user because there is a newer package with all the same characteristics (min OS version, architecture, platform, etc...) that the Store will give to users instead.

As of commit ...b805db4, StoreBroker inspects all of the appx files in the payload and adds additional relevant metadata about those packages to the final json. This additional metadata should be sufficient for determining which packages will become irrelevant once the cloned submission is published.

The goal for -UpdatePackages would be to mark only those redundant packages as PendingDelete, leaving the existing ones as Uploaded. It would then add the new ones as PendingUpload, as it already does today for the other two switches.

[HowardWolosky]

Progress on this is currently blocked at the moment, as it appears that the Dev Portal (and thus, the API) is always returning back that the active packages in a submission are Neutral. This of course is a problem if a package is only for a specific architecture, since we're then unable to automatically determine whether or not one of the new packages in the StoreBroker payload makes these existing packages "redundant".

[HowardWolosky]

I think that progress on this might be possible to unblock some users, despite the bug with the API.
We should implement the behavior exactly as it should be authored, assuming that the API worked, but if anyone tries to use the switch, it should immediately fail, pointing them to documentation that indicates that they would have to set a global variable to "opt-in" to using the switch. This would be a workaround for wanting to ask the user for confirmation at run-time that they want to use the feature despite the potential bug involved.

In the end, with the global variable set, the only apps that would be able to use the feature would be ones that are only actually publishing Neutral packages. If apps are publishing architecture-specific packages, they'll never be able to use it since we'll never know the architecture of the packages already in the submission. In the neutral scenario, there's the possibility that our logic will be wrong since the API might return back an architecture-specific package as a "neutral" package, but that's why we'll have that opt-in global var -- users will need to know the limitations of the API and decide if they want to proceed.

[HowardWolosky]

A fully-working version is about to be checked-in to the v2 branch, since the blocking issues in the API have been fixed with the v2 API.