RFR: Bitmap based ShHeapRegionSet

[Roman Kennke]

For the partial-traversal change I need a datastructure similar to our
current ShCollectionSet: I need to be abled to tell for an address
whether or not it is contained in one of the regions that are in the
set. Instead of introducing yet another class we decided to replace the
current ShHeapRegionSet with a biased-map based implementation.

- Replace the ShenandoahHeapRegionSet* _regions in ShHeap with a fixed
ShenandoahHeapRegion** array.
- Access regions via ShHeap::get_region(idx)
- Add an iterator ShenandoahRegionIterator to iterate all regions
- In a few places (e.g. ShMarkCompact) where it's really benefitial to
use an array-backed region-list, we can just as well use
GrowableArray<ShenandoahHeapRegion*> which, as it turns out, is almost
exactly the same thing as the old ShenandoahHeapRegionSet (it's even
sortable)
- We used a little nasty trick to implement degenerate update-refs: we
carry over the implicit state of iteration of ShHeapRegionSet
(current_index) from the concurrent phase to the STW degen phase to
finish off the remaining regions. This is changed a little bit by using
a ShenandoahHeap field _update_refs_iterator to keep the iterator intact
from init-update-refs to final-update-refs.
- For ShenandoahRegionIterator I don't see the point to distinguish
between concurrent and single-threaded versions for next(): it's simply
using Atomic::add() and thus can be used for both, and the penalty for
single-threaded should be small and not worth the hassle because
single-threaded use doesn't seem *that* performance critical anyway.
- The new ShHeapRegionSet is basically like ShCollectionSet, but with
the cset specific stuff ripped out.

Tests: hotspot_gc_shenandoah (release/fastdebug), specjvm
(release/fastdebug)

http://cr.openjdk.java.net/~rkennke/bitmaphrs/webrev.00/

Thanks, Roman