Method probe should consider where clauses on method

Given:

use core::ops::Deref;

struct W<T>(T);
struct X;

impl<T> Deref for W<T> {
    type Target = X;
    fn deref(&self) -> &Self::Target { &X }
}

trait A {}
trait B {}

impl<T: A> W<T> {
    fn a(&self) {} // EXAMPLE A
}
impl<T> W<T> {
    fn b(&self) where T: B {}  // EXAMPLE B
}

impl X {
    fn a(&self) {}
    fn b(&self) {}
}

fn main() {
    let w = W(());
    w.a(); // Works.
    w.b(); // Doesn't work.
}

I expected this code to work. Whether I place the where clause on the impl block (like in example A) or on the method (like in example B) should not matter.

Method probing should assemble the method's "own" where clauses so we can use them. This would've prevented the regression in https://github.com/rust-lang/rust/issues/129601, since #129449 rearranged some where clause bounds for readability.

Let's not actually fix this until the new solver has landed, since it's likely to cause spurious new overflows in practice, which are fatal. In the new solver, it should be fine 👍

We could technically support this in the old solver, if we were to filter out any predicates that mention the method's generics. But this seems to be a hack that I'd need convincing is worthwhile rather than waiting to do it the "right" way...

There's also theoretically more places for incompleteness to guide inference on the args, but I expect that to not be an issue TBH, since we already (afaict) process obligations before/while doing argument checking.

Start with the Rust reproducer and compare method probing for the impl-level bound in example A with the method-level where clause in example B. Read the new solver work first, then verify that method probing assembles the method's own clauses without causing spurious overflows; the reproducer should work in both cases.