RFR: Heuristics should do concurrent cycles

[Aleksey Shipilev]

http://cr.openjdk.java.net/~shade/shenandoah/heuristics-concurrent/webrev.01/

This is the pack of 4 changes that make heuristics do concurrent cycles consistently. It consists of
the following changes:

 *) Make heuristics tell if we can process references or unload classes

 This adds can_* methods to heuristics, so it can say if it possibly can, but not necessarily should
either process the references or unload classes right now. This simplifies the dependencies all over
the GC code that either polls flags directly, or otherwise guesses on different things.

 *) Factor out implicit/explicit GC requests

 This rewrites the handling for "requested" and "explicit" GCs. Before, "explicit" was the subtype
of "requested" GC, which is confusing both conceptually and code-wise. Instead, there is now the
split between "explicit" (e.g. forced by user action) and "implicit" (e.g. coming from some other VM
facility) GCs. Recent metadata-induced GCs are the examples of implicit GCs.

Additionally, both implicit and explicit GCs always process references and unload classes -- and
they know that they can by polling new can_* methods. And they can do that without diving into Full GC.

 *) Print special cause for Metadata GC

 This moves the special "cause" message to control thread. This makes sure cause is printed only
when GC cycle is actually happening, which makes vmTestbase/metaspace tests happy.

 *) Concurrent cycle by default on any external GC request

 This makes Shenandoah react with concurrent GC on any GC request by default. This makes sure that
users would not get accidentally exposed to either Degen or Full GC in all normal uses, and it would
only happen if something goes really wrong. This is accomplished by defaulting to new values for
*GCInvokesConcurrent, which are also overridable. This is possible after all three things above are
done.


Testing: tier3_gc_shenandoah, vmTestbase/metaspace/ -XX:+UseShenandoahGC

Thanks,
-Aleksey