Introduce:
 - new capability: can_get_gc_cpu_time
 - new JVMTI function: GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)

From Jonas Norlinder:

> But it is not clear if it worth to have similar API's in both MXBeans and JVMTI.

This class serves various use cases throughout the VM, for MXBeans we will only expose MemoryMXBean.getTotalGcCpuTime() and I think JVMTI can be limited to GetTotalGCCpuTime as well. While we can expose each component that makes up the total I don't know how useful that is, nor who really needs such fine detail.

> Also, it is not clear yet what kind of tools (JVMTI agents) may need this extension.

I think it is beneficial for at least two cases: agents that want to analyze cost of (1) different GC algorithms (academia) and (2) heap size guidance.

# 1. Academia

One of the most influential GC researchers (Steve Blackburn) have proposed using a method to estimate GC cost by attributing cost metrics to the GC. Several papers have used this method at this point. They have developed a method that uses a JVMTI agent that hooks into GarbageCollectionStart/GarbageCollectionEnd which gives them a very rough estimation on process level (they use perf counters) what GC costs are during pauses. However only measuring pauses is quite subpar for anything that is not Serial or Parallel. As such introducing a JVMTI function GetTotalGCCpuTime could be of great benefit for cost analysis.

# 2. Heap Size Guidance

We have two GC JEPs in draft mode https://openjdk.org/jeps/8329758 and https://openjdk.org/jeps/8359211 that will automatically set heap size using GC CPU. These JEPs are pre-dated by a paper where @eosterlu and others showed that using GC CPU can be a very effective metric to guide heap size. Moreover we have a patch that Google contributed to expose GC CPU in hsperf counters. Google have an internal tool that can give you a recommendation on what heap size you should run (so not automatic like our JEP drafts). Apparently, they have used such approach internally (see mail thread) to great success.
The above goes to show that this metric carries explanatory power that some users might be interested in and having the ability to track GC CPU time with JVMTI agents when/if automatic heap sizing is integrated could help augment users understandings. Moreover if users don't want to use automatic heap sizing for some reason they might still be interested in this metric to guide their own heap tuning.