Isolate MMTk-related code.

[wks]

Currently, the code base, especially gc.c, is littered with ad-hoc #ifdef MMTK blocks. While it works, it is better if we can isolate MMTk-related functions and data structures into a dedicated source file, such as mmtk.c.

There are some difficulties doing so.

1. Some functions and macros can only be accessed from gc.c. They are related to object layouts, marking, sweeping and so on. gc.c has been the only source file related to GC in the Ruby code base. This may explain why there has never been a need to expose any GC implementation details to other files.
   • gc.c is large, too, having about 16000 lines of code. Although it is much better than the 35000+ lines of code in gc.cpp in .NET core (See Discussion on reorganizing gc.cpp dotnet/runtime#4024 and the avatar of https://github.com/Maoni0), it is still very hard to maintain.
2. There isn't a "VM-GC interface" that makes GC pluggable. In comparison, OpenJDK 10 did a major refactoring on the GC code, and it is now able to put every GC algorithms in a separate directory. This refactoring is also key to making it possible to make MMTk one of its GC provider. See https://openjdk.org/jeps/304

Isolating MMTk-related code is one small step towards making a well-defined VM-GC interface for Ruby, because the places that need to be changed indicates the difference between GC implementations as well as places where the GC is too tightly coupled with the VM.

[wks]

We isolated most MMTk-related functions into mmtk_support.c and mmtk_support.h. There are still changes guarded by #if USE_MMTK in gc.c. Those things are mainly related to object allocation, object scanning, write barrier, and weak table / finalization / obj_free handling. Some of the weak tables are fields of the private struct objspace, such as id_to_obj_tbl and obj_to_id_tbl. We also expose some private functions in gc.c that needs to be called by mmtk, such as gc_mark_root for root scanning, gc_mark_children for scanning objects and functions for executing obj_free.

We should further separate functions that are specific to MMTK and functions that modifies the Ruby VM's behaviours in areas closely related to GC. The latter includes weak reference and finalization. That will also help Ruby isolate GC into a separate module and allow CRuby to switch between different GC implementations. See https://bugs.ruby-lang.org/issues/20470