VersionRange causes issues when packages have multiple DisplayVersion

Brief description of your issue

In a manifest, different installers can have different DisplayVersion. Because of the way the matching logic works, a range is created encompassing the highest and lowest version within the manifest. Between two manifests, the version ranges are not allowed to overlap.

This causes issues when the display versions are vastly different between installers. Take Zoom.Zoom for example - The exe installer writes 5.17.2 (29988) while the msi writes 5.17.29988. This means that the version range is calculated as 5.17.2 - 5.17.29988. When version 5.17.3 is released, it is seen as a version range overlap because it is greater than 5.17.2 and less than 5.17.29988. This makes it impossible to achieve correct version mapping for Zoom.

Steps to reproduce

https://github.com/microsoft/winget-pkgs/pull/137363

Expected behavior

I expect that when a DisplayVersion is in the manifest, the ARP entry must exactly match that version. If different installers have different DisplayVersion, then an exact match would be required with a DisplayVersion corresponding to an installer to determine the manifest version

Actual behavior

https://github.com/microsoft/winget-pkgs/pull/137363#issuecomment-1920517444

Environment

Winget 1.5 through 1.7-preview

Start by reviewing the reproduction linked in PR 137363 and the referenced actual-behavior comment, using the stated WinGet 1.5 through 1.7-preview environment as context. Trace the VersionRange matching path for manifests with multiple DisplayVersion values. Done means a DisplayVersion matches exactly, while differing installer versions still map correctly without an incorrect range overlap.