Remove exception WRT same-crate non_exhaustive reads

[traviscross]

Stabilization:

• Make operational semantics of pattern matching independent of crate and module rust#150681

When matching against a single-variant enum marked non_exhaustive and defined in a different crate, we pretend that there might be multiple variants and force a read of the discriminant. In Rust PR 150681, we decided to remove the same-crate exception. Now matching against a single-variant non_exhaustive enum in the same crate will also cause a discriminant read.

Separately, prior to Rust PR 150681, rustc was eliding the discriminant read when an enum has only one inhabited variant. This contradicts what the Reference says in:

r[type.closure.capture.precision.discriminants.uninhabited-variants]
Even if all variants but the one being matched against are uninhabited, making the pattern [irrefutable][patterns.refutable], the discriminant is still read if it otherwise would be.

We decided with our lang FCP to confirm the behavior already encoded in the Reference, so no change is needed there.

cc @meithecatte @ehuss

[meithecatte]

While we're at it, I feel like the "if it otherwise would be" here can be kind of confusing... do you have any ideas on how to rephrase this? Maybe this would be an improvement?

Suggested change

	Even if all variants but the one being matched against are uninhabited, making the pattern [irrefutable][patterns.refutable], the discriminant is still read if it otherwise would be.
	Even if all variants but the one being matched against are uninhabited, making the pattern [irrefutable][patterns.refutable], the discriminant is still read when it otherwise would be.

[meithecatte]

Regardless of my comment above, I do agree that this PR is enough to document the changes being done by #150681... apart from the subtlety that the change doesn't only affect closure captures. Indeed, this whole section on discriminant reads should probably be moved out of the section on closures entirely – but that's a bigger refactor that can probably be done later (especially since we'd probably end up trying to document more of the runtime semantics of patterns).

(and yeah, I do realize that I was the one who put this text in that part of the reference in the first place, but in my defense, at the time I was only making compiler changes to the closure capture rules specifically 😅)