RFR: 8238761: Asynchronous handshakes

[Robbin Ehn]

This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes
are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime)
Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an
arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a
singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first
pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first
pointer also CAS.

The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake operations matching
the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything except asynchronous
handshakes. In this initial change-set there is no need to do any other filtering. If needed filtering can easily be
exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake operation to be done
out-order. Since the filter determins who execute the operation and not the invoked method, there is now only one
method to call when handshaking one thread.

Some comments about the changes:
- HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake
  all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much
  worse then this.

- I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that
  thread.

- Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a
  handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation.

- Added WB testing method.

- Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did.

- Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking.

- VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a
  safepoint and half of them after, in many handshake all operations.

- ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe.

- Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the
  moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows.

- Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to the NoSafepointVerifyer.

- Added filtered queue and gtest for it.

Passes multiple t1-8 runs.
Been through some pre-reviwing.

-------------

Commit messages:
 - Rebase version 1.0

Changes: https://git.openjdk.java.net/jdk/pull/151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8238761
  Stats: 1047 lines in 24 files changed: 693 ins; 150 del; 204 mod
  Patch: https://git.openjdk.java.net/jdk/pull/151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151

PR: https://git.openjdk.java.net/jdk/pull/151