Handshakes and locking improvements

In some scenarios when using handshakes is favored there is locking mechanism (most common a Mutex) involved.
Many of the Mutexes require that we do safepoint check before locking it. This have two problems:
* The handshake state is protected (as of now with a semaphore) we can thus deadlock if locking order is not correct.
(As part of "8238761: Asynchronous handshakes" this changed to a Mutex)
* Safepointing inside a handshake break the assumption that per thread resources are safe inside the handshake, since they are also safe to modify inside a safepoint. If the JavaThread stops for a safepoint in a handshake any such per thread resource may have changed after the safepoint but while still in the handshake.

One train of thought is to add a NoSafepointVerifyer, and thus make sure we do not block or transition inside the handshake.
(as of now safepoint checking is not allowed/untested but not enforced)

The other train is to instead is to allow it and make sure it works.