Support GC detection for 3.1.0+

[dalehamel]

What

When we are running GC, we insert dummy frames to indicate the GC state, and not unwind the ruby stack:

Why

When GC runs, we are no longer actually running the interpreter code. The current approach will erroneously attribute the GC native frames to whatever the state of the ruby VM is, even though that ruby stack had nothing to do with the triggering of GC.

This also allows us to keep track of GC overhead very easily, as the various GC modes (predominantly marking and sweeping) are grouped under a single "garbage collection" frame.

How

Taking inspiration from stackprof, we copy the same convention they use for dummy frames:

https://github.com/tmm1/stackprof/blob/8085169f071b2e25d5d798482bd1737e012af877/ext/stackprof/stackprof.c#L29-L33

This gives us a similar view to what stackprof request profiles:

Only we get additional details, we can see the actual native code that the ruby VM is running.

To do this, we will check objspace for the flags that indicate if gc is running, and if so, in which mode. If GC is running, we push a special "GC" frame type indicating what GC mode we are in, and handle this accordingly on the userspace side.

[dalehamel]

Upstream PR opened open-telemetry#1101

[dalehamel]

Merged upstream