wip Re-enable RUBY_FREE_AT_EXIT

This is a non-optimal solution. MMTK doesn't provide any kind of
shutdown hook from what I can find and the heap walking implementation
takes a snapshot of the heap, so it's problematic to run GC or mutator
threads at the same time.

I think a better solution would be to implement a shutdown mechanism
inside MMTK core that can safely free everything, but I need to talk to
Kunshan about how this is implemented.

After this work `leaks` on macOS is still reporting ~20 leaks with
`RUBY_FREE_AT_EXIT` enabled and ~200 without, some of these leaks are
coming from within MMTk's allocators, and a few are still coming from
the use of `realloc` inside Ruby.

I suspect that we won't be able to clean up all of these without making
changes to mmtk-core

gc/mmtk.c

@@ -559,8 +559,9 @@ rb_mmtk_obj_free_iter_wrapper(VALUE obj, void *data)
 static void each_object(struct objspace *objspace, int (*func)(VALUE, void *), void *data);
 
 void rb_gc_impl_shutdown_free_objects(void *objspace_ptr) {
-    // TODO (@mattvh) Fix test fails
-    // each_object(objspace_ptr, rb_mmtk_obj_free_iter_wrapper, objspace_ptr);
+    mmtk_set_gc_enabled(false);
+    each_object(objspace_ptr, rb_mmtk_obj_free_iter_wrapper, objspace_ptr);
+    mmtk_set_gc_enabled(true);
 }
 
 // GC
@@ -970,7 +971,9 @@ rb_gc_impl_make_zombie(void *objspace_ptr, VALUE obj, void (*dfree)(void *), voi
         prev = RUBY_ATOMIC_PTR_CAS(objspace->finalizer_jobs, job->next, job);
     } while (prev != job->next);
 
-    rb_postponed_job_trigger(objspace->finalizer_postponed_job);
+    if (objspace->finalizer_postponed_job) {
+        rb_postponed_job_trigger(objspace->finalizer_postponed_job);
+    }
 }
 
 VALUE