RFR: JDK-8209667: Explicit barriers for C1/LIR

[Roman Kennke]

I am x-posting this to hotspot-gc-dev and hotspot-compiler-dev because
it touches both.

In order to support GCs like Shenandoah, we need some explicit read- or
write-barriers in a few places. We already introduced them in the
runtime and interpreter, this change intends to do the same for C1 (at
least the LIR part, will followup with a few C1/assembly ones soon).

The places are based on a few years of Shenandoah development experience
and are:
- CRC32 intrinsics
- vectorizedMismatch intrinsic
- NIOCheckIndex instrinc

The barriers are created via the BarrierSetC1 API, which is a no-op by
default. Similar to what we did with interpreter, it allows to pass
ACCESS_READ and/or ACCESS_WRITE to it to indicate the required strength
of the barrier. Also, similar to what we did in interpreter, this
defaults to ACCESS_READ|ACCESS_WRITE if no such strength indicator is
passed, i.e. the maximum strength.

Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8209667/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8209667

Testing: hotspot/tier1 locally

Can I please get a review?
Thank you,
Roman