Add `note` explaining that the same variant of the same enum with different type params are different types

[estebank]

As brought up in #51479, Result<A, i32>::Err(0) and Result<B, i32>::Err(0) are not of the same type. We should add a note (or ideally a structured suggestion on what to write) explaining this.

error[E0308]: `match` arms have incompatible types
 --> src/lib.rs:8:16
  |
6 | /     match f2() {
7 | |         Ok(value) => Ok(value as i64),
  | |                      ---------------- this is found to be of type `Result<i64, String>`
8 | |         err => err,
  | |                ^^^ expected `i64`, found `i32`
9 | |     }
  | |_____- `match` arms have incompatible types
  |
  = note: expected enum `Result<i64, _>`
             found enum `Result<i32, _>`

[SparrowLii]

@rustbot claim

[SparrowLii]

I tried to implement it but got stuck. The biggest question is how to determine that they are "the same variant". For example, in the above err => err statement, we can only know that err is of type Result<_, _> rather than the specific Result<_, _>::Err(..)variant.

I was going to use rustc_mir_build::thir::pattern::usefulness::compute_match_usefulness which checks whether a match is exhaustive. From the result returned by this function, we can know whether the pat in a certain arm can be determined to be a specific variant. But this function runs after typeck and needs the result of typeck, so it cannot be used in the current scenario.

[compiler-errors]

Removing E-easy because this doesn't seem that easy. The fact that match arms can have arbitrary patterns does make this quite difficult to, e.g., suggest changing err => err to Err(x) => Err(x)... Curious what the structured suggestion would ideally look like here.