Apparently when using RBASIC_CLASS() sometimes Ruby returns something
that _looks_ like a VALUE but isn't. This results in Ruby sometimes
treating it as a Fixnum of sorts while in other cases it just segfaults.

To work around this we're now using rb_tracearg_defined_class() to get
an object class, which seems to be the correct way of doing it (based on
digging through the MRI source code).

One small nuisance is that we now also get singleton classes which we
generally don't care about (since there's always only one of them). This
means we'll need to filter these out whenever we generate a Ruby Hash
containing the counts per class. Of course MRI doesn't provide a sane
API for this (that doesn't involve calling Ruby methods) so we instead
use the same logic as MRI's implementation of Class#singleton_class?
uses.

This allows us to define a custom mark/free function using
Data_Wrap_Struct. This in turn makes the code a bit more robust by
marking objects that are counted so they're not garbage collected by
accident.

Sometimes, for whatever reason, this output may contain instances of
objects. For example, in a test script I ended up with an Enumerable
instance in the output (which then triggers an error as Enumerable
doesn't respond to #hash). I have no idea how on earth an Enumerable can
1) get initialized since it's a module 2) ends up in the output.

In rare circumstances locking/unlocking a Mutex may lead to an object
allocation which in turn crashes CRuby when this happens during a GC
run. Since the GIL already prevents multiple Ruby threads from running
in parallel we should be able to safely remove the usage of explicit
mutexes without breaking things.

By just stuffing these into the Allocations module as a constant we can
prevent them from being GC'd.