Differentiate emitted metrics by configuration options

[jaydeluca]

Related to #13468

This change introduces another system property (metaDataConfig) that we can set during our test runs to help us identify a when condition for which the telemetry data is emitted. This way, we can run separate test suites in order to generate telemetry under different conditions and tag it accordingly.

Example new metrics .telemetry file contents:

when: otel.semconv-stability.opt-in=database
metrics:
  - name: db.client.connection.max
    description: The maximum number of open connections allowed.
    type: LONG_SUM
    unit: connection
    attributes: 
      - name: db.client.connection.pool.name
        type: STRING
...

Then, when we present the telemetry in the instrumentation-list.yaml file, we can differentiate when someone could expect to see the different telemetry. This provides a nice preview of the database semconv differences, as an example:

telemetry:
- when: default
  metrics:
  - name: db.client.connections.max
    description: The maximum number of open connections allowed.
    type: LONG_SUM
    unit: connections
    attributes:
    - name: pool.name
      type: STRING
...
- when: otel.semconv-stability.opt-in=database
  metrics:
  - name: db.client.connection.max
    description: The maximum number of open connections allowed.
    type: LONG_SUM
    unit: connection
    attributes:
    - name: db.client.connection.pool.name
      type: STRING
...

I turned it on for a handful of the existing modules we were already collecting metadata for. I will follow this up with enabling it for every instrumentation I can find that emits metrics.

I also made some small changes to a few modules to setup the tests to run in a way that would be compatible with this setup (oshi, tomcat-jdbc, clickhouse)

[trask]

Suggested change

	- when: 'otel.semconv-stability.opt-in=database '
	- when: otel.semconv-stability.opt-in=database

[trask]

can remove this conditional I think (and just let it iterate over empty map below)