normalizing impl headers before proving constraining projection where-clauses causes unnecessary errors due to `param_env` preference

trait Proj {
    type Assoc;
}

struct IncorrectGuidance<T>(T);
impl<T> Proj for IncorrectGuidance<T> {
    type Assoc = T;
}

trait BreakMe<T> {}
impl<T, U> BreakMe<<IncorrectGuidance<U> as Proj>::Assoc> for T
where
    T: Proj<Assoc = U>,
{}

fn break_me<T: BreakMe<U>, U>() {}
fn check<T, U, V>()
where
    T: Proj<Assoc = U>,
    IncorrectGuidance<V>: Proj, // removing this line makes it compile
{
    break_me::<T, U>();
}

Caused by https://rustc-dev-guide.rust-lang.org/solve/candidate-preference.html#preference-over-impl-candidates

when proving T: BreakMe<U> we try to use the impl impl<T, U> BreakMe<<IncorrectGuidance<U> as Proj>::Assoc> for T. Doing so goes through the following steps:

• instantiate the impl header with infer vars, giving us the TraitRef ?t: BreakMe<<IncorrectGuidance<?u> as Proj>::Assoc>
• normalize the impl header to equate it with the goal. This normalizes <IncorrectGuidance<?u> as Proj>::Assoc via the IncorrectGuidance<V>: Proj where-clause, incorrectly constraining ?u to V
• only then would we prove the ?t: Proj<Assoc = ?u> where-bound which is what should constrain ?u

The way this differs from e.g. https://github.com/rust-lang/rust/issues/24066 is that the goal we're proving doesn't actually reference any inference variables, so there is no way for the user to avoid this incorrect inference guidance

Start by compiling the reduced Rust example and read the candidate-preference section of the rustc-dev-guide. Trace how the impl header is normalized before its where-clause is proven, focusing on the param_env preference described in the issue. Done means the example no longer produces the unnecessary error without regressing the stated candidate-preference behavior.