Auto merge of #113470 - compiler-errors:new-solver-structurally-resolve-pat, r=lcnr

Structurally resolve in pattern matching when peeling refs in new solver

Let me know if you want me to commit the minimized test:
```rust
fn test() {}

fn test2() {}

fn main() {
    let tests: &[(_, fn())] = &[
        ("test", test),
        ("test2", test2),
    ];

    for (a, b) in tests {
        todo!();
    }
}
```

In that test above, the match scrutinee is `<std::vec::Iter<(&'static str, fn())> as Iterator>::Item`, which we cannot peel the refs from.

We also need to structurally resolve in the loop, since structural resolve is inherently shallow. I haven't come up with a test where this matters, but I can if you care.

Also,  I removed two other calls to `resolve_vars_with_obligations` in diagnostics code that I'm pretty convinced are not useful.

r? `@lcnr`

compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs

@@ -1640,6 +1640,8 @@ impl<'tcx> InferCtxtPrivExt<'tcx> for TypeErrCtxt<'_, 'tcx> {
                     )
                     .into(),
                 };
+                // FIXME(-Ztrait-solver=next): For diagnostic purposes, it would be nice
+                // to deeply normalize this type.
                 let normalized_term =
                     ocx.normalize(&obligation.cause, obligation.param_env, unnormalized_term);