Add T: PartialEq bounds to derived StructuralPartialEq impls.

[kpreid]

Fixes #147714.

Currently has a severe regression in diagnostic quality — suggesting derive(PartialEq) on the type that already has that derive — apparently because the diagnostic logic effectively checks whether StructuralPartialEq exists as a proxy for whether the type has the derive. I don’t yet know how to solve that problem.

This is a breaking change to fix a bug, so it will need a crater run if it is to be done at all.

[kpreid]

This PR is probably less correct than the just-posted #156809, because the documentation of StructuralPartialEq says that it ensures that “interpreting the value of the constant as a pattern is equivalent to calling PartialEq”, and so the trait bounds should require transitive StructuralPartialEq, not just that the applicable PartialEq impl is the derived one. Still, I'll leave this open until things settle down more.

Currently waiting on an answer to my question about a route to to fixing the diagnostics.

[theemathas]

Adding T: StructuralPartialEq bounds like in #156809 is incorrect. Consider the following code, which compiles in current stable rust, despite Box not implementing StructuralPartialEq:

const X: Option<Box<()>> = None;

fn main() {
    if let X = X {}
}

[theemathas]

Relevant documentation: https://doc.rust-lang.org/nightly/reference/patterns.html#r-patterns.const

The StructuralPartialEq trait does not correspond to the concept of "structural equality" in the documentation. In fact, this concept of "structural equality" cannot be represented as a trait at all, due to the "active variant" clause for enums, which makes structural equality depend on the const's value, not just the type.

Instead, the StructuralPartialEq trait corresponds to some notion of "shallow" structural equality, which is not written down in the reference.