RFR: 8191870: Remove badJNIHandle

[Kim Barrett]

Please review this change to eliminate badJNIHandle and the special
debug-only handling of it when resolving JNI handles.

For the intended purpose of catching bad JNI handle usage while
sometimes normalizing some to NULL, we mostly don't need such a
special value. We can instead use NULL directly, and get largely the
same effect.

By filling blocks with NULL, rather than badJNIHandle, we avoid the
difficulties related to the Access protocol (see the CR).

A NULL value is sufficient for local and non-weak global handles.  A
JNI handle is never allocated to refer to a NULL value; instead, a
NULL handle is used.  resolve and friends already treat the case of a
NULL pointee specially (asserting, except in the external guard case,
where it is allowed to pass through).

Only weak global handles lose the protection afforded by badJNIHandle.
(This is because, unlike local and global handles, a weak global
handle can refer to a NULL value, because it may have been cleared by
the GC.)  That protection was already fairly minimal for such handles,
even when using badJNIHandle.  That protection only applied for
entries in a newly allocated block that have never yet been allocated.
Blocks in the global lists are currently never released, so the
setting to a "bad" value for released handles never occurs for weak
global handles.  So the most interesting use-case for badJNIHandle
(identifying uses of stale handles) doesn't even apply.

There is one other use of badJNIHandle: throw_unsatisfied_link_error.
This function isn't currently called, only used as a marker.  The
discussion in bug 4524377, where that function was added, suggested
using badAddress, so we're replacing badJNIHandle with badAddress.

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

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

Testing:
Mach5 hs-tier1-3
tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests)