RFR: jsr166 jdk9 integration wave 7

[Martin Buchholz]

jsr166 has been pervasively modified to use VarHandles, but there are some
other pending changes (that cannot be cleanly separated from VarHandle
conversion).  We expect this to be the last feature integration for jdk9.

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

We're asking Paul to do most of the review work here, as owner of
VarHandles JEP and as Oracle employee.
We need approval for API changes in

https://bugs.openjdk.java.net/browse/JDK-8157523
Various improvements to ForkJoin/SubmissionPublisher code

https://bugs.openjdk.java.net/browse/JDK-8080603
Replace Unsafe with VarHandle in java.util.concurrent classes

There is currently a VarHandle bootstrap problem with
ThreadLocal/AtomicInteger that causes
java/util/Locale/Bug4152725.java
to fail.  Again I'm hoping that Paul will figure out what to do.  In the
past rearranging the order of operations in <clinit> has worked for similar
problems.  It's not surprising we have problems, since j.u.c. needs
VarHandles initialized to do work, and j.l.invoke needs j.u.c. (notably
AtomicInteger and ConcurrentHashMap) to do work.  Maybe we need some very
low-level concurrency infrastructure that does not use VarHandles, only for
bootstrap?