Fixes for updating winget from winget

[JohnMcPMS]

Fixes #4283

Change

The primary issue here is that the package update monitoring is too aggressive at shutting down, and I made it listen to signal in more cases. It really isn't a good signal for us to listen to, and was only added for the elevated Store case. The fix is to move it entirely to the Store flow, as if we are installing via MSIX we can just let the deferred registration work and if someone else is updating us then we can just listen to the proper termination signals.

I additionally noticed that the dependencies were being installed despite the fact that I definitely already had them up to date. There were a few issues here that I also fixed:

• An MSIX nested inside an archive that was expecting to inherit the PackageFamilyName from the root node of the manifest was not doing so if the installer type was also inherited. Inheriting the installer type info before the PFN resolved this (for Microsoft.VCLibs.14).
• An exe installer that installs an MSIX that was expecting to inherit the PackageFamilyName from the root node of the manifest was not doing so. I allowed the PFN to be inherited when the AppsAndFeaturesEntries has an MSIX type (for Microsoft.WindowsAppRuntime.*).
• MSIX packages were not being allowed to map display versions, so I enabled them.
• There was a bug with display version sorting that would not map the sort key of the "first" version when multiple versions are installed. This could lead to the first version in the list not being the latest version per the mapping.

Validation

Added unit tests for the alternate issues.
Unfortunately, fully testing the primary issue is not feasible until we get an official build. The documented impact should be gone based on debugging the current version, but any unintended side effects will need manual testing of the build in the Store prior to expanded release.

Microsoft Reviewers: Open in CodeFlow