SPEC + TCK: make JVM base metrics be optional

[donbourne]

JVM/thread/classloading/operating-system metrics should be optional due to the availability of suitable metrics from other metrics libraries that could be used for this purpose.

micrometer and open telemetry have their own sets of metrics for these no sense having MP metrics define yet another set

for example, see https://micrometer.io/docs/ref/jvm

            new ClassLoaderMetrics().bindTo(registry); (1)
            new JvmMemoryMetrics().bindTo(registry); (2)
            new JvmGcMetrics().bindTo(registry); (3)
            new ProcessorMetrics().bindTo(registry); (4)
            new JvmThreadMetrics().bindTo(registry); (5)

vendors may choose to add sets of metrics from micrometer / otel or whichever metrics libraries they are using as the implementation of the MP Metrics api

this will increase interoperability between servers using MP Metrics and other servers using the underlying metrics libraries vendors choose to implement with

should note that vendors can also provide any other vendor metrics they want - encouraged to use otel semantic conventions where applicable (https://opentelemetry.io/docs/reference/specification/metrics/semantic_conventions/

[Channyboy]

Future release?

[donbourne]

I'll mark it as not part of Milestone 5 for now. part of rationale is that we can continue to provide the same set of metrics for backward compatibility

[donbourne]

based on our last meeting, we want to give implementors the option of whether they want to include the base metrics or not as part of milestone 5.0

[donbourne]

closing as this is addressed by #729 and #730