Rollup merge of #153847 - traviscross:TC/fix-typeoutlives-missing-param-check, r=lcnr

Fix marker trait winnowing depending on impl order

Story: I was looking through this code for an unrelated reason and happened to notice the duplicate condition.  That seemed obviously wrong, especially in light of the comment, so I worked backward to what it affected, wrote a test that failed, and then found that the test matched an existing `known-bug` test, which pointed me to rust-lang/rust#109481.

---

The `TypeOutlives` handler in `evaluate_predicate_recursively` means to check whether a type in a `T: 'a` predicate has free regions, bound regions, non-region inference variables, or non-region generic parameters -- and if so, to return `EvaluatedToOkModuloRegions` rather than `EvaluatedToOk`.  Correspondingly, the comment says "no free lifetimes or generic parameters".  But the code was mistakenly checking `has_non_region_infer()` twice instead of checking both `has_non_region_infer()` and `has_non_region_param()`.

This meant that `TypeOutlives(T, 'static)` where `T` is a type parameter returned `EvaluatedToOk` -- claiming the result holds unconditionally -- when the correct answer is `EvaluatedToOkModuloRegions`.

The distinction matters during marker trait winnowing in `prefer_lhs_over_victim`, which uses `must_apply_considering_regions()` (true only for `EvaluatedToOk`) to decide whether one impl beats another when there are multiple candidates.  With the bug, a `T: 'static`-bounded impl appeared equally as strong as an unrestricted impl, making the winner depend on source order.  This caused spurious E0310 errors when the more-constrained impl happened to appear after the less-constrained one.

Fixes rust-lang/rust#109481.

This same symptom was originally filed as rust-lang/rust#84917 and fixed in PR rust-lang/rust#88139.  Then PR rust-lang/rust#102472 rewrote the `TypeOutlives` handler, introducing the duplicate `has_non_region_infer()` and losing the param check, regressing this. Around this same time, rust-lang/rust#109481 was filed.  It noted the connection to rust-lang/rust#102472 -- the bug only appeared after it -- but the duplicate condition was not noticed.

r? @lcnr

cc @oli-obk @nikomatsakis