Add process.runtime.jvm.cpu.time metric

[trask]

We have debated whether to reuse process.cpu.time, and we are currently leaning towards introducing process.runtime.jvm.cpu.time, primarily in order to avoid issues and confusion when process.cpu.time is also captured by the collector.

Even though the "instrumentation scope" and resource attributes will be different when process.cpu.time is captured by the collector:

• it is still the same thing being observed from two different sources, which could lead to confusion
• aggregating across both process.cpu.time emitted by the collector and process.cpu.time emitted by the JVM would end up double counting CPU usage
• some backends may (accidentally) try to merge these
• some UIs may not make this distinction clear, e.g. when trying to show runtime metrics and associated collector process metrics at the same time

process.runtime.jvm.cpu.time has the added benefit of being clear that this is the CPU time that is reported by the JVM (we aren't scraping metrics from the O/S).

[jack-berg]

Only concern is that this is setting a precedent to define new metrics rather than reusing existing ones even when same semantics can be achieved.