RFR: Fix (external) heap iteration

[Roman Kennke]

I've extracted this from the 1-bitmap patch that I posted recently 
because it is a somewhat independent issue and an actual bug.

There are three methods in CollectedHeap to support heap object 
iteration: object_iterate() safe_object_iterate() and 
ensure_parsability(). Those need to be able to called at anytime (but 
during a safepoint). This is used by JVMTI, heap inspection code and 
some few other places.

I have written a testcase to exercise JVMTI heap iteration code (i.e. do 
several 100s of heap iterations with aggressive heuristics), and sure 
enough we crash spectacularily.

The problem is that we can not always scan the heap safely. We might 
have unreachable objects that have a dead Klass* (due to recent 
concurrent class unloading), and dead objects might point to 
non-existing objects. Etc etc.

The only really safe solution that I see is to traverse the heap from 
roots, much like we do in marking. I implemented object_iterate() as a 
heap traversal, supported by an auxiliary bitmap that I commit only on 
demand, and a marking stack. This makes the testcase work well.

Notice that since we're not scanning linearily, we also don't need to 
make the heap parsable either. In fact, attempting to do so while evac 
is in progress would lead to crashes too (evacuating threads don't stop 
for safepoint!). I changed it to be a no-op.

Shenandoah internal code still does fast linear scans (and make TLABs 
parsable for this), because it is under our control and we only do it 
when we know that it's safe.

http://cr.openjdk.java.net/~rkennke/heapiter/webrev.00/ 
<http://cr.openjdk.java.net/%7Erkennke/heapiter/webrev.00/>

Test: hotspot_gc_shenandoah (incl. new JVMTI test)