Rework smallest_range_containing to handle duplicates

[scottmcm]

@theemathas pointed out that this method I added in #159509 is implicitly assuming that there are no duplicates in the input. That's not a problem for its one use today -- an enum whose layout matters can't have duplicate discriminants -- but it could be a sharp edge in future, so this PR reworks it to handle duplicate values fine.

As a bonus, as I tried a couple different approaches (from just asserting to deduping to more) I found this rephrasing that I think is clearer. In particular, while the .iter().copied().cycle().skip(1) I'd written works, it's definitely not something that you look at and think "oh, obviously". I think this version using .array_windows::<2>() is easier to follow and splitting the wraparound and non-wraparound cases also simplifies the min_by_key lambda.

No changes to any layouts from this -- it just refactors this function.

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: codegen, compiler
• codegen, compiler expanded to 74 candidates
• Random selection from 17 candidates

[nnethercote]

The new code makes sense. Some observations from someone who doesn't know anything about enum representation stuff...

• WrappingRange is a really weird type.
• smallest_range_containing is a really weird operation on a really weird type.
• The docs for smallest_range_containing contain only one case where the WrappingRange actually wraps, which seems low because that's trickier than the non-wrapping case.

View changes since this review

[nnethercote]

r=me if you want it, after considering the comment above.