feat: add aggregated rocksdb metrics

[rodesai]

This patch adds a pattern for computing/reporting metrics that return aggregates
of the rocksdb metrics added by KIP-607. Additionally, this particular PR adds the
following metrics:

num-running-compactions-total: the total number of running compactions
estimate-num-keys-total: an estimate of the total number of rocksdb keys
block-cache-usage-total: total memory usage of all block cache
block-cache-pinned-usage-total: total memory used by pinned blocks
estimate-table-readers-mem-total: estimate of the total table readers mem

ksqlDB registers for notification about new rocksdb metrics by creating a
MetricsReporter implementation called RocksDBMetricCollector. The metrics
system calls into MetricsReporter.metricChange when a new metric is added.
RocksDBMetricCollector looks out for rocksdb property metrics it cares about
and tracks them under the relevant aggregates. Each aggregate is registered
with the ksql metrics context on the first instantiation of
RocksDBMetricCollector.

Metrics are computed lazily when read, and are rate-limited to a configurable
interval. The interval is set using the property
ksql.rocksdb.metrics.update.interval.seconds

One alternative I considered was to dynamically add the metrics as they are sent
to RocksDBMetricCollector.metricChange (rather than hard-coding a static list).
Opted not to do this in case we add metrics in the future that use different types,
or want to compute different aggregates (e.g. for some metrics maybe a max or
average makes more sense)

Testing done

Ran our aggregation benchmark with these metrics collected and 1000 partitions
and didn't see any perf regression (processing rate 39098 records/second)

[vvcephei]

Thanks, @rodesai , looks reasonable to me!