Auto merge of #116821 - Nadrieril:fix-opaque-ice, r=compiler-errors

Exhaustiveness: reveal opaque types properly

Previously, exhaustiveness had no clear policy around opaque types. In this PR I propose the following policy: within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.

I'm not sure how consistent this is with other operations allowed on opaque types; I believe this will require FCP.

From what I can tell, this doesn't change anything for non-empty types.

The observable changes are:
- when the real type is uninhabited, matches within the defining scopes can now rely on that for exhaustiveness, e.g.:

```rust
#[derive(Copy, Clone)]
enum Void {}
fn return_never_rpit(x: Void) -> impl Copy {
    if false {
        match return_never_rpit(x) {}
    }
    x
}
```
- this properly fixes ICEs like rust-lang/rust#117100 that occurred because a same match could have some patterns where the type is revealed and some where it is not.

Bonus subtle point: if `x` is opaque, a match like `match x { ("", "") => {} ... }` will constrain its type ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=901d715330eac40339b4016ac566d6c3)). This is not the case for `match x {}`: this will not constain the type, and will only compile if something else constrains the type to be empty.

Fixes rust-lang/rust#117100

r? `@oli-obk`

Edited for precision of the wording

[Included](rust-lang/rust#116821 (comment)) in the FCP on this PR is this rule:

> Within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.

Author: bors