Explicit return 0 compiler snack
Using the same source and target in snprintf is undefined behavior

According to the man page: "For those routines that write to a
user-provided character string, that string and the format strings
should not overlap, as the behavior is undefined".
Always push finalization information on the front

There might be multiple objects that need finalization that depend on
each other. The only really sensible case is an object that is created
later depends on an object created earlier. If both objects needs
finalization, the latest created object should be finalized first.

Changing this ordering here makes sure newest objects are finalized
first, so we work with a LIFO here instead of FIFO.
Reset method cache after defining a method through the C-API

This was problematic with the FFI extension. Problem was that because of
not resetting the method cache, if a function was redefined, Rubinius
would keep using the old cached definition. When that old definition was
cleaned up, since nothing in Ruby land referred to it anymore, it could
crash because of memory already been freed and reused.
Run all finalizers through the scheduling

This is another case where dependencies between finalizers can be
tricky. Data_Wrap_Struct uses a C finalizer for the free function if
that is requested. That means that this data gets cleaned up before any
other finalizers could run that depend on this data.

By treating all finalizers equally here, we can make sure that the
ordering of defining finalizers is also the reverse of when they are
executed.
Objects with a Ruby finalizer might also have a handle

Also unremembers these objects when they are remembered.
Zlib can be compiled with RSTRING_NOT_MODIFIED

Even though the zlib extension uses RSTRING_PTR and also modifies these
buffers, these cases aren't problematic. The ByteArray backing the
string is pinned so it won't move and there don't seem to be
dependencies on string sizes that could be handled wrong here.
Prevent Data from being freed twice and marking when freed

There are situations where something happens to hold onto finalized
data, for example in the finalizer itself. Whatever does this or however
this happens, we should prevent double marking and free'ing here as a
safety net.

These objects usually get cleanup up then in the next cycle, it could
for example be that finalization was in progress at that time for those
objects when doing the GC.