kvserver: track per-replica and aggregate to-apply entry bytes

**Is your feature request related to a problem? Please describe.**

In recent experiments @andrewbaptist, found[^1] that because log entry *append* is sequential whereas log entry *application* can cause random writes to the LSM, a node that catches up on a log of raft log (for example after restarting following a period of downtime) can end up with an inverted LSM that results from applying a large amount of rapidly appended log entries.

This can be seen in the screenshot below. The top graph shows the inverted LSM - higher is more inverted. The middle graph shows log appends - they level off way before the LSM fully inverts. (As a result, replica pausing in the bottom graph comes too late, as that only delays *appending* which at this point in time has already completed).

Similar to how writes to the LSM don't account for compaction debt, appends to the raft log are even a step further back, because they don't even account for the writes to the LSM (which may have very different characteristics than the appends themselves, as we see here).

It's desirable to be able to change something about this behavior, but this issue does not attempt to propose a solution. Instead, we note that it would be helpful to at least have a quantity that can detect this debt before it inverts the LSM, as this will likely play a role in both short-term and long-term mitigations to this kind of overload.


**Describe the solution you'd like**

We could track the number of unapplied entry bytes per replica and also maintain a store-global aggregate. Per Replica, we would have a gauge `unappliedEntryBytes` which tracks all bytes between the `AppliedIndex` and the `LastIndex`[^2]. Any change to this gauge would be reflected in a store-aggregate gauge, which could be read off quickly without a need to visit all replicas.

The gauge would need to be updated on raft log appends (taking care to do this properly on sideloading and also when the log tail is replaced), and on snapshots. Thanks to the local copy of the gauge, the global one can be "partially reset" accordingly.

**Describe alternatives you've considered**

**Additional context**

[^1]: https://cockroachlabs.slack.com/archives/G01G8LK77DK/p1675457831537829?thread_ts=1675371760.534349&cid=G01G8LK77DK
[^2]: it's likely unimportant whether we use the durable or inflight last-index, the inflight one likely makes more sense.

Jira issue: CRDB-24481