Report ZGC individual collections instead of cycles (#445)

[akiselev98]

Previously, the ZGC parser would attempt to construct a single event for each minor/major cycle, with each minor cycle containing a single young collection, and each major cycle containing a single young and a single old collection.

This created a few problems.

First, the implementation of the parser assumed that only one cycle could be active at any given time. As a result, any time a minor cycle started before the previous major cycle was finished, all data collected about the major cycle would be lost.

Second, the data model for a MajorZGCCycle assumed there could be only one young collection per cycle. This is not the case. There can be (and frequently are) multiple young collections in a major cycle.

Even if the implementation and datamodel were fixed to account for the concurrent nature of generational ZGC, grouping collections by cycle would still create API usability problems. Individual collections within a cycle independently report various JVM/heap level metrics at specific points in time. Within a single major cycle, those points in time may be very far apart, and overlap with a large number of minor cycles. If an end user wished to construct a timeline for a particular metric (for example, heap occupancy), they would need to traverse all the reported cycles, extract the metrics from the individual collections, and put them in order.

To address the above issues, the parser and data models are refactored to report each individual collection (young, old, or full) immediately once they are completed instead of waiting until the parent cycle is done. The parser maintains 3 independent forward references (one for each collection type: old, young, and full). As a result, the parser will not lose state even when lines from an old collection are intermixed with lines from a young collection.

[akiselev98]

@microsoft-github-policy-service agree company="IMC Markets N.A."

[akiselev98]

There's still a few minor naming inconsistencies I'd like to resolve (i.e. ZGCCollectionType could be more accurately described as ZGCCycleType, and ZGCPhase could be more accurately described as ZGCCollectionType), but figured I could save that for a second pass.

[karianna]

This looks clean to me overall

[karianna]

@dsgrieve / @kcpeppe - in case you wanted to comment - else I'll merge this in 42-48 hours.

[dsgrieve]

LGTM. This change does break API.

[karianna]

LGTM. This change does break API.

Fair, would require version bump if we're being semantic