RFR: Factor out storeval barrier from read barriers

[Roman Kennke]

Work on concurrent partial GC has shown that it makes sense to name and
treat the storeval barriers different than read barriers. When
traversal, evacuation and update all happens in the same phase (as in
conc partial GC), then we do need a write barrier instead of a read
barrier. Plus, in C2 land, we have treated storeval barriers slightly
different for a while (optimizes slightly differently).

This patch adds a new interface for storeval barriers in runtime,
interpreter, c1 and c2, and makes all previous uses of read barrier use
that instead. The implementation still generates the same read barriers
as before, but that's going to change with conc partial GC.

I also added a flag ShenandoahStoreValBarriers that does the same as the
other ShenandoahXXXBarriers flag, turn generation of the barriers off on
request. The way it's currently done, the storeval barrier is also
controlled by ShenandoahReadBarriers, dunno if we want to change that?
I.e. -ShReadBarrier not affect ShStoreValBarrier ?

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

Tested on x86 only (I hope aarch64 is correct, code looks trivial
enough): hotspot_gc_shenandoah

Ok?

Roman