Measure read latency of single row SQL reads done by users, without capturing contention or hardware queueing

**Is your feature request related to a problem? Please describe.**
Would be nice to measure point read latency of single row SQL reads done by users, without capturing contention or hardware overload. CRDB should deliver predictable performance for single row SQL reads.

**Describe the solution you'd like**
Implement `kv.replica_read_batch_evaluate.single_row.latency`. Similar to `kv.replica_read_batch_evaluate.latency` but only captures read requests that touch a single SQL row (or similar e.g. allow joins by FK). @rytaft suggests a way to check if a read touch just one SQL row at https://github.com/cockroachdb/cockroach/issues/71169#issuecomment-1049857896. We could do the check in SQL land, attach some metadata to the context indicating that only a single SQL row is affected, then plumb that into `BatchRequest` like we do with tracing info, then plumb into `kvserver` context, the use to implement `kv.replica_read_batch_evaluate.single_row.latency`.

**Describe alternatives you've considered**
https://github.com/cockroachdb/cockroach/issues/71169 is a more complete solution but will take much longer to implement.

**Additional context**
This will help with:
1. SRE alerting.
2. Disaggregated storage rollout to CC, as we need to know what latency we are currently providing our users to decide on the right caching solution.

Jira issue: CRDB-25182