do not prefer trivially true candidates with -Znext-solver

[lcnr]

This is for the sake future compatibility, see https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/resolving.20equal.20regions/near/623504310 for more background. Integrated changes to make this not cause any crater regression, see #133502 (comment) where we did an accidental crater run only for this change.

I would generally like us to not be region dependent at all. For this we need the following:

• stalled_on shouldn't have to track region variables
• my hope is that we can yeet region uniquification once we have OR constraints

For this to work candidate merging has to always merge the region constraints of all candidates and can't rely on there being no region constraints. This in turn means that as long as there's an ambiguous candidate, we can't use another candidate which is known to hold, as the ambiguous candidate may end up resulting in fewer region constraints than the existing options.

This change does prevent us from discarding HeadUsages of other where-bounds if one where-bound holds without any constraints. This will cause hangs if we allow using a non-rigid ParamEnv for normalization in rust-lang/trait-system-refactor-initiative#210.

This also has annoying interactions with weakening impl shadowing. I am really unsure about the long-term plan here. We may revert this change in the future because the tradeoff isn't worth it, unsure. By doing it for now we're future compatible with whatever we want to do.

The cycle handling tests are better tested by https://github.com/lcnr/search_graph_fuzz, having subtle cycle handling tests as ui tests is very brittle and very easily stops testing the right thing.

cc rust-lang/trait-system-refactor-initiative#305, see the added test

r? types

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.