RFR: Fallback to shared allocation if GCLAB is not available

[Aleksey Shipilev]

Looking at some failures I suspected some system threads still do not have
GCLABs. Then it struck me that we can rewire the logic to check if GCLAB is
available, and fallback to shared allocation if GCLAB is not there. This turns
executing write barriers from the threads that miss GCLABs into a performance
nuisance, not a catastrophic bug.

Fix:
  http://cr.openjdk.java.net/~shade/shenandoah/gclabs-fallback/webrev.01/

This reverts parts of "All threads should have GCLABs" changeset:
  http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/aa7cdfe4fabe

We now make sure that only Java threads and GC worker threads are having GCLABs,
because most GCLAB allocations will come from them. Which limits our upstream
exposure too, because we don't need to track any system thread.

Testing: hotspot_gc_shenandoah

Thanks,
-Aleksey