JRuby's caching call sites should gather better metrics, use those metrics to deoptimize smartly, and allow tuning thresholds

From JRUBY-2478: I discovered the degradation was actually due to a flaw in the test: because the classes under test were singletons, and because they were recreated repeatedly during the course of the test, the monomorphic (control) test eventually flipped polymorphic, causing the call sites to deoptimize. This does potentially cause a small concern, since sites that are "mostly monomorphic" may still benefit from caching even if they are "occasionally polymorphic". We also have too few metrics being gathered on call sites to either know what's a good deoptimzation threshold or how well the call sites are working.

This bug is to ensure we add in metrics. A good strategy may be to look at what metrics SmallTalk et al gather, since they very likely have similar polymorphic challenges.

This will also play into any eventual PIC that replaces the current inline caches.