kv: establish new read snapshot on statement/batch boundaries under RC

Closes #100133.

This commit teaches Read Committed transactions to establish a new
external "read snapshot" on each SQL statement or KV batch boundary.

The per-statement/batch read snapshot logic is integrated into the
transaction `Stepping` infrastructure in an analogous manner to how the
transaction's internal `readSeq` is advanced. For transactions with
stepping enabled (e.g. SQL transactions), the `Step` API now advances
the transaction's external read snapshot (i.e. `ReadTimestamp`) to a
timestamp captured from the local HLC clock. This ensures that
subsequent read-only operations observe the writes of other transactions
that were committed before the time the statement began. For transactions
with stepping disabled (e.g. raw KV transactions), each batch implicitly
advances the read snapshot. This ensures that the batch observes the
writes of other transactions that were committed before the batch was
issued.

This read snapshot will be at least as recent as the previous read
snapshot, and will typically be more recent (i.e. it will never
regress). Consistency with prior reads in the transaction is not
maintained, so reads of previously read keys may not be "repeatable" and
may observe "phantoms". On the other hand, by not maintaining
consistency between read snapshots, isolation-related retries
(write-write conflicts) and consistency-related retries (uncertainty
errors) have a higher chance of being refreshed away (client-side or
server-side) without need for client intervention (i.e. without
requiring a statement-level retry). This benefit can be seen in
`TestTxnCoordSenderRetries`.

As described in the Read Committed RFC, the transaction's uncertainty
interval is not reset when establishing a new read snapshot. See section
"Read Uncertainty Intervals" of the RFC for the rationale behind this
decision.

Release note: None