Generate valid_ranges for enums sign-agnostically

[scottmcm]

Prompted by #159438 (comment), 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), 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 #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 i128ing 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.

[rustbot]

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[scottmcm]

Ok, the first version I'd misunderstood how we need to pick tag signedness, so redid that and added a bunch of new tests because there were disturbingly few failures when I'd probably broken a ton of stuff (albeit subtly).

OP updated as well to describe the fixed approach.
@rustbot ready

[scottmcm]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 8d18ada (8d18adad4abcffe08e2c9c56e062fe6826106354)
Base parent: eff8269 (eff8269f797067c30555e77f160ec84c0ed15cd9)

[rust-timer]

Finished benchmarking commit (8d18ada): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Results (primary -2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.4%	[-2.4%, -2.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.4%	[-2.4%, -2.4%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 489.126s -> 483.723s (-1.10%)
Artifact size: 389.52 MiB -> 389.47 MiB (-0.01%)