Use WeakRef to track inheritance for serial increments

This sets up weakrefs for each module where we track modules or classes
that this module is included into or that this class is a parent of.
This allows us to increase the serial when a method is added to a
certain module or class. In that case we bump the serial of all the
classes below in the hierarchy so they get invalidated as well.
Use class_id for inline caches and add serial property

With this change we keep track of a serial per class and the combination
of the class_id and the serial_id is used to invalidate inline caches.
This means that we can remove the inline cache registry in the future
and do inline cache invalidation pure on these serials.

This is pretty much the same strategy as JRuby uses. It trades
invaliding caches based on classes for on name. This means that we
should have a lot less invalidations and we don't need the relatively
expensive operation of removing all caches with the same name.
Setup serial increases in proper places
Check inline cache with knowledge whether the cache grows

This makes sure we don't move to polymorphic caches when we are going to
replace a cache entry for the same class id because the serial changed.
Cleanup no longer needed InlineCacheRegistry

With the serial invalidation strategy the registry is not longer needed
to keep track of all inline caches.
Unify serial increases and global method cache clearing

In all cases both these were called, so unifying them gives us a nice
cleanup.
Also check against serial for cache checks
Add helper for checking against class id

This is used when only the class id is what needs to be checked, for
example for accessing ivars where the current serial is irrelevant for
the object layout.
Create separate blocks for serial mismatch and class mismatch

This is so we can do an immediate deopt in the case of a serial
mismatch, since those will never be properly recovered anyway so we
shouldn't use a normal uncommon exit, but one that immediately
deoptimizes.
Add immediate deoptimization if the serial check fails

Since we know that the code will never run when the serial mismatches,
we can do an immediate deoptimization. Also reset the call count in that
case to prevent everything from being recompiled immediately after.
Add a very simple name cache for invalidation

We only invalidate here when we see a new method name we've seen
before. This results in faster startup and in for example not having to
flush everything when for example the Rational() method is added on
Object.