RFR (sh/8): Fix lock ordering issue when calling JVMTI GetLoadedClasses during marking

[Roman Kennke]

Alexey Genus reported a lock ordering issue involving JVMTI
GetLoadedClasses() during concurrent marking.

ClassLoaderData::loaded_classes_do() acquires the "Metaspace allocation
lock/5" and LoadedClassesClosure tries to enqueue it into G1's SATB
queue, thus attempts to acquire "SATB_Q_CBL_mon/16"

It is not Shenandoah specific, but would also affect G1. See discussion
and G1 testcase:
https://bugs.openjdk.java.net/browse/JDK-8234096

However, it is jdk8u specific. It's been fixed in jdk10 timeframe by
making loaded-classes-iteration lock-free.

As far as I can tell, it is not fatal in release build, but it seems
prudent to fix it anyway, especially because the fix is not difficult.
Simply not enqueue the oops during loaded_classes_do() but instead
during extraction of the jclasses, where the Metaspace allocation lock
is not held.

While this could go completely via upstream jdk8u, I'd like to push this
in Shenandoah first, to get it into the hands of Alexey for testing, and
to bake it a little.

Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8234096-shenandoah/webrev.00/

Testing: The provided testcase fails without the fix, and passes with
the fix. hotspot_gc_shenandoah looks good.

Ok to push?

Roman