When an index spans a daylight savings time transition we can't use our
optimization that rewrites the requested time zone to a fixed time zone
and instead we used to fall back to a java.util.time based rounding
implementation. In elastic#55559 we optimized "time unit" rounding. This
optimizes "time interval" rounding.

The java.util.time based implementation is about 1650% slower than the
rounding implementation for a fixed time zone. This replaces it with a
similar optimization that is only about 30% slower than the fixed time
zone. The java.util.time implementation allocates a ton of short lived
objects but the optimized implementation doesn't. So it *might* end up
being faster than the microbenchmarks imply.

This fixes a bug in the interval rounding and two test bugs that showed
up when I ran 1000s of iterations of the tests. The bug was that we
could end up with duplicate transitions if we only needed the last
transition from the list of fully defined transitions and the
transitions overlapped with the rules. This happens. Its ok. We had
defence against that if we needed more than one transition but forgot it
in this case. Now we have it and assertions to make sure we catch any
similar mistakes.

One test bug had to do with the randomized test calling
`round(round(min))` because sometimes the first `round` call will return
a time less than min. Specifically if `min` is near daylight savings
time. Anyway, this change fixes it by building an extra-wide prepared
rounding just in case.

The other test bug came up when adding a test for the real bug, namely
that `assertRoundingAtOffset` made an assertion that wasn't true if the
time to round ended up being in an overlap. This just drops that
assertion. We have similar assertions in cases where we *know* what kind
of offsets we're working with in other tests.

Closes elastic#56400