concurrency: consider wait metrics by request category

**Describe the problem**

The latency of BatchRequests include time spent waiting for various forms of contention, most notably:

- Latch wait times
- Lock wait times

For the former we currently have a standard histogram metric and for the latter we record a max and average metric.

While we expect latch wait times to be relatively low even in the face of contention, lock wait times can be arbitrarily large, historically making metrics here less useful.

However, as we work on non-blocking, non-locking reads, we expect some categories of requests (namely read-only batches) to experience much lower lock wait times.

We should extend our metrics to get a signal about whether we are actually achieving that goal in production installations. One way to do that would be to have a histogram on lock and latch wait times that were broken down by the type of batch (say: "admin", "read-only", "read-write"). We would then be able to track "read-only" wait times in a cluster without detailed knowledge of its workload.

Jira issue: CRDB-57985

Start by locating the BatchRequests implementation and the existing latch and lock wait metrics described in the issue. Determine how request categories such as admin, read-only, and read-write are represented, then verify that the resulting wait-time signals distinguish those categories in production-oriented metrics.

Written by the indexing model from the issue text.