There are a number of HsPerf counters that would be useful to track within the JVM to get a better understanding of where CPU time is spent when doing GC.

More specifically, we should introduce counters that track the various CPU time spent in various phases of GC. For example, time spent in:

- Parallel GC: CPU time consumed by parallel GC worker threads, updated after every stop-the-world collection.
- G1 Concurrent Mark (Only available for G1): CPU time consumed by ConcurrentMark thread and concurrent GC worker threads, updated after concurrent root scan, concurrent mark, concurrent cleanup and at the end of a concurrent cycle.
- G1 Concurrent Refine (Only available for G1): CPU time consumed by ConcurrentG1RefineThread threads, updated every time the main worker thread finishes its share of refinement work.
- Concurrent String Dedupliation (Available with +UseStringDeduplication): CPU time consumed by concurrent string deduplication thread, updated every time it finishes processing pending deduplication work.
- VM Thread Time: CPU time consumed by the VMThread, updated after executing every VM_Operation.


For context, the value of these counters was discussed briefly in the context of Container-aware heap sizing: https://mail.openjdk.org/pipermail/hotspot-gc-dev/2022-October/040433.html



--------------------------

Open Questions:

1. Do we want to support these metrics for other GCs, given that the main use case for these counters are for Container-aware heap sizing, which is planned to only be supported for G1GC (for now)?
- From Google's perspective, I suggest we focus on G1GC, and expand porting these metrics to other GCs if we find it to be useful. This PR has implemented the counters for G1 and ParallelGC.
2. Is there is a better way to report these metrics besides hsperf counters (i.e. `sun.management.HotspotInternal` MBeans, JFR events, or parsing `/proc`)?
- From Google's perspective, the work done with Container-aware heap sizing was done using these hsperf counters, so this would be the smoothest option for us to bring this project upstream without having to re-architect and re-validate our work. Thus, we strongly prefer this implementation.


---------------------

Update: the final hsperf counters added are:

sun.threads.total_gc_cpu_time
sun.threads.cpu_time.gc_parallel_workers
sun.threads.cpu_time.gc_conc_mark
sun.threads.cpu_time.gc_conc_refine
sun.threads.cpu_time.gc_service
sun.threads.cpu_time.vm
sun.threads.cpu_time.conc_dedup