RFR: 8194312: Support parallel and concurrent JNI global handle processing

[Kim Barrett]

Please review this change to the implementation of JNI global and weak
global handles, providing infrastructure for parallel and concurrent
processing of such handles.

This change introduces OopStorage, a data structure for managing
off-heap references to objects allocated in the Java heap. JNI global
and weak global handles are reimplemented using OopStorage, rather
than using JNIHandleBlock. (JNI local handles continue to use
JNIHandleBlock; the lifetime management and concurrency issues are
very different for local vs global handles.)

This change does not change any GCs to use the new parallel and
concurrent capabilities, only laying the foundations for doing so.

Other uses of OopStorage are also being considered, in the context of
runtime latency improvements for ZGC and other collectors. The idea is
to change some (often weak) oop references in runtime data structures
to OopStorage-managed handles, simplifying the GC processing and
avoiding (potentially concurrent) GC walks of runtime data structures.

As a side effect, this enhancement fixes these bugs:
8174790: Race adding (weak) global JNI handles and determining type of handle
8176454: Performance: jweak references not suitable for robust cache architecture

Some things not addressed by this change include:

- 8194309: JNI handle allocation failure not reported correctly  
For now, the pre-existing vm_exit_out_of_memory behavior is retained.

- Updating JNIHandles to use the new Access protocol.

- Serviceability Agent updates for OopStorage and JNI usage.  Just
enough has been done to allow existing SA tests to "pass".  This will
be addressed as a followup.

CR:
https://bugs.openjdk.java.net/browse/JDK-8194312

Webrev:
http://cr.openjdk.java.net/~kbarrett/8194312/open.00/

Testing:
Mach5 hs-tier1 through hs-tier5, jdk-nightly