Solver: Combine "skipped" versions with previous "rejected" version when possible

[sebright]

Here is the error message that is currently produced by cabal when a package has an unsatisfiable dependency like in #4251. (I modified cabal-testsuite.cabal to require a later version for aeson.)

Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: cabal-testsuite-3 (user goal)
[__1] next goal: aeson (dependency of cabal-testsuite)
[__1] rejecting: aeson-2.2.3.0 (conflict: cabal-testsuite => aeson>=3.0 && <3.1)
[__1] skipping: aeson; 2.2.2.0, 2.2.1.0, 2.2.0.0, 2.1.2.1, 2.1.2.0, 2.1.1.0, 2.1.0.0, 2.0.3.0, 2.0.2.0, 2.0.1.0, 2.0.0.0, 1.5.6.0, 1.5.5.1, 1.5.5.0, 1.5.4.1, 1.5.4.0, 1.5.3.0, 1.5.2.0, 1.5.1.0, 1.5.0.0, 1.4.7.1, 1.4.7.0, 1.4.6.0, 1.4.5.0, 1.4.4.0, 1.4.3.0, 1.4.2.0, 1.4.1.0, 1.4.0.0, 1.3.1.1, 1.3.1.0, 1.3.0.0, 1.2.4.0, 1.2.3.0, 1.2.2.0, 1.2.1.0, 1.2.0.0, 1.1.2.0, 1.1.1.0, 1.1.0.0, 1.0.2.1, 1.0.2.0, 1.0.1.0, 1.0.0.0, 0.11.3.0, 0.11.2.1, 0.11.2.0, 0.11.1.4, 0.11.1.3, 0.11.1.2, 0.11.1.1, 0.11.1.0, 0.11.0.0, 0.9.0.1, 0.9.0.0, 0.8.1.1, 0.8.1.0, 0.8.0.2, 0.7.0.6, 0.7.0.4, 0.6.2.1, 0.6.2.0, 0.6.1.0, 0.6.0.2, 0.6.0.1, 0.6.0.0, 0.5.0.0, 0.4.0.1, 0.4.0.0, 0.3.2.14, 0.3.2.13, 0.3.2.12, 0.3.2.11, 0.3.2.10, 0.3.2.9, 0.3.2.8, 0.3.2.7, 0.3.2.6, 0.3.2.5, 0.3.2.4, 0.3.2.3, 0.3.2.2, 0.3.2.1, 0.3.2.0, 0.3.1.1, 0.3.1.0, 0.3.0.0, 0.2.0.0, 0.1.0.0, 0.10.0.0, 0.8.0.1, 0.8.0.0, 0.7.0.5, 0.7.0.3, 0.7.0.2, 0.7.0.1, 0.7.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=3.0 && <3.1' from 'cabal-testsuite')
[__1] fail (backjumping, conflict set: aeson, cabal-testsuite)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: cabal-testsuite, aeson

I think that it would be clearer to combine all of the versions after "skipping" with the previous "rejecting" message, since they describe the same conflict in this case. Combining the lines would also allow us to summarize the versions more effectively, as in #9831.

[sebright]

I realized that the "skipping" mechanism may be more efficient than applying all of the usual validation, even when the version can be rejected without descending farther down the tree. We should probably solve this issue by simplifying the solver log at the end of dependency solving rather than changing the algorithm for skipping versions.