Fix Prometheus registry metadata for prom-client-java upgrades

[zeitlinger]

Summary

Tests added on the Prometheus side to support repeated prom-client-java
upgrade work exposed this issue in Micrometer.

In this case, the compatibility testing did not only show a prom-side problem.
It also showed a necessary Micrometer-side change in the prometheusmetrics
adapter.

This draft contains the change we currently believe Micrometer will need when
moving to the newer prom-client-java release line.

What this changes

• expose the actual Prometheus family metadata from MicrometerCollector
• align registration-time metadata in PrometheusMeterRegistry with the
  MetricSnapshot metadata used at scrape time
• make collision validation use the same names, types, and labels that the
  scrape path will actually emit

Why this is draft

We'd like feedback from Micrometer maintainers on whether this is the right
Micrometer-side fix.

Context

• Prometheus-side compatibility workflow:
  feat: add micrometer compatibility workflow zeitlinger/client_java#1
• related prom-client-java fix:
  fix: restore legacy suffix compatibility prometheus/client_java#2100
• we also noticed that the downstream-adapter implication was not explicit in
  the Prometheus-side release notes/docs, so that is being clarified here:
  docs: clarify downstream adapter validation requirements prometheus/client_java#2101

[zeitlinger]

I made it ready for review - let me know what you think.

[zeitlinger]

Superseded by #7487, which switches Micrometer to the new typed family descriptor API from prometheus/client_java#2114. Closing this older prototype so review can focus on the end-state design.