Remove GCRequester, move related code to GCTrigger

[qinsoon]

This PR moves GC triggering related code to GCTrigger, including:

• The old GCRequester which handles the request for GCs.
• The check for is_collection_enabled in memory_manager and Space::acquire.
• Code for user collection request and internal collection request in MMTK.

[qinsoon]

This PR was originally created to support a fix for #1398. By consolidating all GC-triggering logic into GCTrigger, it becomes easier (or possible) to apply locks or atomics to address the data race when enabling collection.

I’ve also prototyped a thread-safe “enable collection” API, but it turned out to be difficult to use from Julia due to the issues described in mmtk/mmtk-julia#278. Since Julia is the main reason we need these APIs, it doesn’t make much sense to introduce them if they don’t integrate well there. As a result, a proper fix for #1398 may be postponed.

Given that said, I think this PR on its own is still a good cleanup, even if there’s no immediate follow-up to fix #1398.

[wks]

Just one minor problem. Other parts look good.

[wks]

This method is identical to GCTrigger::plan. Keep one of them and move the other.

[qinsoon]

Done. I didn't realize we had that function.

[wks]

LGTM See comment below

Still things worth updating.

[wks]

I grepped the code and found there are still comments mentioning the GCRequester type. We should update those comments, too.

And the eBPF tools capture.bt and visualize.py also contains the USDT name gcrequester_request. It can be renamed (e.g. simply change it to gc_requested)

[qinsoon]

Done. I further pushed a change for memory_manager::gc_poll (which no longer needs to check is_collection_enabled -- gc_trigger.poll will check is_collection_enabled)

[wks]

LGTM