Restrict the resolver to only consider the latest patch version per major-minor version tuple.

[lassepe]

Motivation
Consider package Foo at version 0.1.0 which has declared compatibility with Bar = ^1. If now Bar makes a change in 1.4 that is breaking Foo (e.g. because Foo was using "internals" of Bar; maybe because there was a misunderstanding of what the API promises), Foo would have to restrict its compat to Bar = 1-1.3.

Current approach
The current way we handle this setting is by making PR's to the registry: https://github.com/JuliaRegistries/General/pulls?q=is%3Apr+label%3A%22compat+fix%22+is%3Aclosed

Downsides of the current approach
While the current approach does the job, in my view it is problematic that a package's Project.toml does not reflect its true compatibility. I find that very confusing from a user's perspective. This concern is amplified by the fact that a package can be registered in multiple registries and thus suddenly the compatibility depends on the registry the package was installed from. In an ideal world, the package's Project.toml should be the single source of truth (wherever possible).

Desired Behavior
Rather than relying on edited compat bounds in the registry, it would be nice if a Package author can just release a new patch version with updated compat bounds. In the example above, the author of Foo would release 0.1.1 with new compat Bar = 1-1.3.

Proposed Approach
If one currently would attempt to release such a patch version, it would not reliably have the desired effect since Pkg may resolve to Foo=0.1.0 and Bar = 1.4 since the old patch release of Foo did not have the constraint on Bar.

To address this issue without relying on manual edits of the registry, we could consider adjusting the ]resolve logic to only consider the latest patch version per major-minor version tuple. That is, the set of versions during ]resolve should be restricted to x.y.$(maxpatch(x.y). In the example above, this would mean that Foo=0.1.0 is never considered when Foo=0.1.1 is released. If the user then tried to install Bar without explicit compat constraints, they would automatically get Bar=1.3. If the user tried to install Bar=1.4, then the resolver would (correctly) throw a compat error.