Make opsem for all enums consistent, independent of number of variants and `#[non_exhaustive]`

[RalfJung]

The way we generate MIR currently means that enum opsem distinguished two classes of enums

• Those with more than 1 variant or a #[non_exhaustive] attribute
• Those with 1 or 0 variants and no #[non_exhaustive]

For the latter, we sometimes omit reading the discriminant since we "already know the result". Also see #150681 where this is point 1.

I think we should treat all enums consistently. This example should be considered UB. In particular, I think #[non_exhaustive] should not affect the opsem.

This change was separated out of #150681 at the request of @traviscross, so that it can be discussed separately. So, let's discuss. :) @scottmcm and @nikomatsakis already expressed agreement with this next step in that PR.

Cc @meithecatte -- IIRC this had a non-zero crater fallout; where are the results of that again?

[workingjubilee]

We can still elide some of these reads as an optimization, right? We just were doing the "optimization" too early? (during MIR building? or another step which is intended to reflect the "actual" mechanics of Rust as opposed to waiting until we are approaching the "realized" machine implementation)

[theemathas]

@workingjubilee The "optimization" currently also affects borrow-checking and closure captures. So yes, the "optimization" is too early. See #147722 (comment)

[theemathas]

Also see #146590 (comment)

[workingjubilee]

Yeah, my bias is to assume this fell out of someone's well-intentioned idea of improving generated code or compiler implementation or maybe ergonomics, or several such micro-ideas accumulating over time, and no one was intending this thing being well-defined to become a fundamental aspect of our semantics. Basically what @CAD97 said here: #150681 (comment)

I'm just confirming my intuition about what should be an "obvious" consequence of winding back and formally declaring it Actually UB is correct in terms of later optimizations we're allowed to perform... after we generate our actual semantics.