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

In order to display a WebKit based webview a plugin will deploy a
temporary standalone executable on the system and host the WebKit
instance inside that.

This is a breaking change - see BREAKING-CHANGES.txt

Co-authored-by: ValentynPavliuchenkoA <valentyn.pavliuchenko@avid.com>

Following commit 093dbc7df1 pings of a
child process connection need to initialised explicitly. This commit
adds a missing initialisation.