New lint proposal: `manual_assert_matches`

What it does

Checks for usage of assert!(matches!(...)) / debug_assert!(matches!(...)) which can be replaced with core::assert_matches!(...) / core::debug_assert_matches!(...).
(namely, when the value being matched on implements Debug)

Advantage

If the assertion fails, core::assert_matches includes the Debug representation of the value being matched on in the panic message, while assert!(matches! only says that the assertion failed.

Drawbacks

This changes the behavior of the program w.r.t. its output.
If something depends on the contents of a panic message (e.g. a test that asserts that something panics with a certain message, or spawning a task and when it panics doing something based on the message), then this might change its behavior.

Example

#[derive(Debug)]
enum A {
    X,
    Y,
}

fn main() {
    let a = A::X;
    assert!(matches!(a, A::Y));
}

Could be written as:

core::assert_matches!(a, A::Y);

Comparison with existing lints

Somewhat similar to the existing explicit_<thing> lints, however this introduces a behavioral change as described above.

Additional Context

Not sure which could be the right category for this, maybe complexity?

Also not sure if behavioral changing lints are allowed in principle, even if in this case the scope of the behavior change is pretty limited. I would imagine one doesn't match on panic messages, and even if they did they would probably match on something more informative than blah blah assertion failed.
If there's a concern about this, maybe we could only apply the lint to test code?