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.

Also remove a stale TODO.

* 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.

These macros have been defined here and there, so collect them.