Rollup merge of #159509 - scottmcm:redo-valid-range, r=oli-obk

Generate `valid_range`s for enums sign-agnostically

Prompted by https://github.com/rust-lang/rust/issues/159438#issuecomment-5007170897, this reworks the generation of the tag layout information for enums.

Having gone down the wrong path at first here, I think the core trouble this is having is that the current calculation is trying to serve two incompatible desires:
- When picking the `value: Primitive`, we need to respect the signedness of the original *discriminant* numbers as typed in Rust.
- When picking the `valid_range: WrappingRange`, we want to *ignore* the signedness (and size!) of the discriminants and look only at the bit values (and size) of the *tags* themselves.

This thus splits the handling in `layout_of_enum` into those two parts, handled differently.
- When looking at *discriminants* (to eventually call [`discr_range_of_repr`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/layout/trait.IntegerExt.html#tymethod.discr_range_of_repr)), we obey the signedness of the inputs to find the smallest negative discriminant and largest positive discriminant -- notably *without* any wraparound logic.
- Then after having used the discriminants to pick a *tag* size, then we run a wrapping-aware check to pick the best `WrappingRange` to represent those tags (which can be a different range than we'd have picked on the discriminants, especially for `repr(Rust)` where the discriminants are `isize`).

With apologies for sending this when you'd said you'd look at it, but I got inspired 😅
r? @oli-obk

Fixes rust-lang/rust#159438

---

I have a bunch of commits in here; it's probably best reviewed one at a time.

1. Just moving `WrappingRange` to its own file, since the `lib.rs` is over 2000 lines already so if I was going to add stuff I figured some reorganizing could help.
2. Adding a new constructor to `WrappingRange` that takes an iterator of values and returns a range containing those values.  Dealing just in `u128` + `Size`, like `WrappingRange` does in other places, it doesn't even *have* signedness information so structurally is prevented from having any "why are `repr(u8)` and `repr(i8) picking different ranges?" issues.  I found it helpful to have this split out from the layout code, for example that it let me put some examples on the doc-comment.  Nothing actually *uses* the new function in this commit though.
3. Stop giving layout discriminants as `i128` since <https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/util/struct.Discr.html#structfield.val> points out that they're generated as `u128` in the same way that `WrappingRange` uses already -- even with the field doc that `-1_i8` is generated as `255_u128`, so the `as i128`ing was probably just making everything more confusing here than it needed to be.
4. Adding some tests looking at the generated `Primitive` and `valid_range`, along with rustc support for `#[rustc_dump_layout(largest_niche)]` to help have these tests include specific ERROR annotations rather than just the stderr.  The tests pass at this point, so the next commit can update them to show the change.
5. This one actually updates layout code, including using the `WrappingRange` constructor added earlier.