RFR/RFC: Shenandoah support for x86_32

[Aleksey Shipilev]

http://cr.openjdk.java.net/~shade/shenandoah/32-bit/webrev.01/

This is the preliminary review request for Shenandoah x86_32 support.

Some history: Shenandoah used to support x86_32 in "passive" mode long time ago. This mode relies
only on stop-the-world GC to avoid implementing barriers (basically, runs Degenerated GC all the
time). It was an interesting mode to see the footprint numbers you can get with uncommits and
slimmer native pointers with really small microservice-size VMs. This mode was dropped before
integration upstream, because many Shenandoah tests expect all heuristics/modes to work properly,
and having the rudimentary x86_32 support was breaking tier1 tests. So we disabled it.

Today, we have significantly simplified runtime interface thanks to LRB [1] and elimination of
separate forwarding pointer slot [2], and we can build the fully concurrent x86_32 on top of that.
This allows us to maintain 32-bit cleanness in Shenandoah code (we have fixed >5 bugs ahead of this
patch!), plus serves are proof of concept that Shenandoah can be implemented on 32-bit platform.

Current patch applies on top of sh/jdk. Compiler changes are mostly to cover a few corner cases that
are needed for !LP64 paths, including the shenandoah_x86_32.ad file that carries Shenandoah CAS
barriers. Otherwise most of the changes are in rewiring ShenandoahBarrierSetAssembler for x86 to
properly share 32- and 64-bit paths. Plus there are test changes that make sure we don't run test we
know would fail on 32-bit VMs.

The patch passes hotspot_gc_shenandoah tests, CTW tests, jcstress (although there are upstream
failures that are being fixed now). Please spot mistakes and problems before I rush to propose it
for inclusion a few weeks later.

-- 
Thanks,
-Aleksey

[1] https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-April/009203.html
[2] https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-May/009480.html