Previously, the Lock was not thread-safe when multiple threads were
locking/unlocking a single Lock instance simultaneously. This
isn't normally a problem when using the MessageManagerLock type, because
each MessageManagerLock contains its own private MessageManager::Lock,
and it's not possible for multiple threads to modify that private lock.

This change improves safety when using a MessageManager::Lock in the
manner of a CriticalSection or other JUCE lock type.

Previously, the following sequence of events was possible:

Background thread                   Main thread
------------------------------------------------------------------------
Lock::tryAcquire()
    Run to blockingMessage->post()

                                    BlockingMessage::messageCallback()
                                        Run to abortWait.set (1)

Lock::tryAcquire()
    Exit through return true

Lock::~Lock()
    Destroy memory used for Lock

                                    BlockingMessage::messageCallback()
                                        Execute lockedEvent.signal()
                                        Memory already freed, crash

See BREAKING-CHANGES.txt for more details.