Reduce (or eliminate) data races in constant cache.

Because previously the constant cache for non-indy and AST used
multiple fields updated independently, there was always a chance
that two threads might splice their updates of those fields
together. This could cause an old value to be cached with a newer
invalidator/generation, resulting in a stale value being returned
forever. While we did not have reports of this in the wild, I
opted to fix it now.

The new caches use an immutable tuple containing all cache data
for a given constant. The tuple is set up as follows:

* Grab the invalidator for the constant name. JRuby, like MRI,
  invalidates constants globally and by name.
* Get the current "generation" object from the invalidator. This
  happens before getting the current value to ensure the
  generation is at least current or older than the value, but
  never newer.
* Get the current value for the constant. If the generation
  changes inbetween acquiring it and getting the value, the worst
  case is that the next read of the constant will have to recache.
* If the constant is acquired from a specific module, save that
  module's Java hashcode. This value never changes, and is used
  to identify that we're still looking at the same module as last
  time.

This does mean an additional object is created for every recache,
and every constant lookup site will eventually have such an object
associated with it, but the additional allocation should be rare
and the memory increase should be negligible.

Note that this issue does not affect invokedynamic-based caching
of constants, since they already store constant cache data within
the method handle tree in a way similar to the new tuple.