Metrics: Consider only storing `TableId` and recover table names in UX

Basically, the idea is that we go back to only storing TableIds in metrics and have the UX later translate the ids to table names, so that the BitCraft team also retain the information.

Relevant resources:

• https://grafana.com/blog/2021/08/04/how-to-use-promql-joins-for-more-effective-queries-of-prometheus-metrics-at-scale/
• https://prometheus.io/docs/prometheus/latest/querying/operators/#one-to-one-vector-matches
• https://www.robustperception.io/left-joins-in-promql/

Possibly what we want is, as an example:

#[name = spacetime_table_names]
#[labels(table_id: u32, table_name: str)]
pub rdb_table_names: IntGaugeVec,

#[name = spacetime_num_table_rows]
#[labels(db: Address, table_id: u32)]
pub rdb_num_table_rows: IntGaugeVec,

and then e.g., the PromQL: spacetime_num_table_rows and on(table_id) spacetimedb_table_names should yield (db, table_id, table_name).

Start by locating the Rust metrics definitions and the UX path that displays table names. Read the linked Prometheus join documentation and determine how table_id and table-name metrics should be related. Done should preserve table IDs in stored metrics while allowing the UX to recover table names through the proposed PromQL join.