jmx metrics provide registry + weaver validation

As described in the discussion of https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/16016

• instrumentation should only produce stable metrics by default, users should be able to opt-in for other metrics.
• JMX metrics are not formally defined nor have stability definition
• some of the target systems do have experimental- prefix to indicate their definitions are not stable
  • this creates breaking changes for users when metrics are promoted
  • this prevent promoting metrics one by one, it's all or nothing
• users have to know the relevant values to use for otel.jmx.target.system in order to get the metrics, whereas the presence of MBeans should be enough to know if a given system needs to be monitored.

In order to solve this, we need to have the following:

• a formal definition of JMX metrics that is consistent with upstream semantic conventions, it should be compatible with the "federated semconv" to be reusable/imported by end users
• having the ability to select JMX metrics on their stability level, rather than having to enumerate the "target system", in other words: "capture what is available in the JMX tree for a given maturity level".
  • doing this automatic discovery is not strictly required here but allows to remove the need to define and maintain the values for otel.jmx.target.system.

Once this is complete we should have:

• otel.jmx.target.system configuration option is optional or deprecated
• added the ability to select JMX metrics on their stability level, the default should be stable.
• a folder in this repository that contains reusable definitions of existing JMX metrics and can be used with a "federated semconv" strategy
• the ability to start formally promoting some of those JMX metrics as stable.

Relates to

• https://github.com/open-telemetry/opentelemetry-java-contrib/issues/2073
• https://github.com/open-telemetry/opentelemetry-java-contrib/issues/2072
• https://github.com/open-telemetry/opentelemetry-java-contrib/issues/2349

Implementation steps

• start registry + validate with integration tests
  • https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/19139
  • tomcat
  • jvm (inherited from semconv)
• add definition and validation with other supported systems
  • activemq
    • #19247
    • fixes https://github.com/open-telemetry/opentelemetry-java-contrib/issues/2349
  • camel #19248
  • wildfly #19246
  • jetty #19249
  • kafka-broker #19722
  • kafka-connect #19724
  • hadoop #19660
  • cassandra #19658
• add the ability to auto-discover all available metrics
  • #19245
  • #19780
• add the ability to filter (or opt-in) metrics on maturity level
  • #19245
  • #19780
• test: find a way to make weaver enforce metrics descriptions/brief for consistency
• test: find a way to ensure jmx metrics stability is in sync with JMX metrics registry

Follow-up step(s)

• optional: promotion of JMX metrics to stable
• required: ensure feature parity in jmx-scraper
• test: validate jmx registry with weaver policies, for example
  • stability
  • naming_conventions

Optional but related step(s)

• optional: automate generation of JMX metrics documentation from registry
• optional: reduce duplication between JMX metrics tests and weaver validation (instrument type, unit, metric description), some aspects are not covered by weaver like:
  • assert on numeric value
  • assert on attribute value, even if it's defined as an enum (all enums are considered "open" and there isn't a "closed enum" concept anymore)
  • assert on metric description
• optional: reduce duplication in metrics definition yaml, either through weaver generation (with annotations), or by providing a way to link to JMX metrics registry definitions.
  • the opposite approach (jmx yaml to registry yaml) was suggested in https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/15196, but this prevents reusing the registry as-is.