Add human-readable metadata to oximeter metrics

At the moment, oximeter metrics use uuids to identify control plane concepts like projects, silos, instances, etc. This works well for the current metrics views in the console, but gets confusing when we run more complicated queries via oxql, or in a future where customers export metrics to external stores. For example, if a customer wants to aggregate vcpu_usage by instance uuid, they would then have to look up the name of each instance of interest in order to make sense of the result. I'm proposing that we add human-readable metadata, like project and silo names, alongside the existing uuids.

I think the most obvious way to handle this would be to add more metadata to the relevant metrics producers. For example, we could add project_name and silo_name fields to the cpu stats producer in propolis.

Alternatively, since we would want to add these labels to many metrics, we could imagine enriching metrics with standard labels in the consumer instead. For example, we could check for a project_id label in oximeter, and add a corresponding project_name field before writing to ClickHouse. This feels a bit too magical, but I wanted to write it down for completeness.

@bnaecker, does this make sense? I'm happy to take at stab at implementing something in the interest of making our dashboards more useful.

Start with bin/propolis-server/src/lib/stats/virtual_machine.rs around the linked metrics producer, then inspect the oximeter path that writes metrics to ClickHouse. Compare producer-side metadata with consumer-side enrichment and clarify which control-plane names must accompany existing UUIDs. Done means the chosen approach adds human-readable metadata consistently to the relevant metrics and supports the proposed oxql or exported-metrics use case.