dfece65 adjusted time-bound iterators to use backwards half-open
intervals, (start, end], as, at the time, the only consumer of the
feature, MVCCIncrementalIterator, used backwards half-open intervals.

This change has proven to be maximally confusing, as other intervals in
the system are typically fully closed [start, end] or forwards half-open
[start, end). When intent resolution was optimized with time-bound
iterators (e510316), the new code erroneously but understandably assumed
that time-bound iterators used forwards half-open intervals. This
off-by-one error could cause major correctness problems: if the upper
bound of an SST exactly matched the start time of a transaction, the
intents in that SST would be invisible to the intent resolver and never
get cleaned up, but the transaction record would get GC'd. At that
point, the intents would become abortable, and the writes from a
committed transaction would get lost.

So, change time-bound iterators to use fully-closed intervals [start,
end]. This effectively prevents off-by-one errors, as even when a more
restrictive interval, like (start, end] or [start, end) is desired,
time-bound iterators will now return too much data instead of too
little. (The consumer has always been required to filter data down to
the desired bounds, since time-bound iterators are only an optimization
and do not guarantee that only data within the provided bounds will be
returned.)

There is a potential performance cost if a scan over (t2, t3] needs to
scan an SST that includes keys in [t1, t2], but this is easily remedied
by transforming scans over (t2, t3] to scans over [t2.Next(), t3].

Writing a targeted test for this is difficult. Our smart compaction
logic makes it hard to create SSTs with specific time bounds to exercise
the bug. Revisit when #21294 is fixed. For now, at least,
TestInitialPartitioning routinely triggers this bug under stress.

Fixes #21539.
Fixes #21538.
Fixes #21526.
Fixes #21514.
Fixes #21501.
Fixes #21500.
Fixes #21494.

Release note: None