Some TYPEDDATA objects allocate struct fields using the GC right after
they get created, and in that case the VM can try to perform a GC and join
a barrier if another ractor started one. If we're dumping the heap in another
ractor, this acquires a barrier and it will call the `rb_obj_memsize` function on this
object. We can't assume these struct fields are non-null. This also goes for C extensions,
which may cause problems with heap dumping from a ractor if their memsize functions aren't
coded correctly to check for NULL fields. Because dumping the heap from a ractor is likely a
rare scenario and it has only recently been introduced, we'll have to see how this works in
practice and if it causes bugs.
* Make invariant `root_box` an array consist of only `root_box_data`.
* Remove the unnecessary initializer list that is just overwritten in
`initialize_root_box()` and missing `classext_cow_classes`.
* Shrink the scope using another local `root_box`.
* Make the data type constants static.
Re-open the exising module by calling `rb_define_module`.
RDoc (`RDoc::Parser::C#do_classes_and_modules`) does not recognize
`rb_path2class` as a class/module definition.
