tdf#119856 vcl: Qt5/KDE5 RunInMainThread

tdf#119856 vcl: Qt5/KDE5 RunInMainThread

The problem with the current approach of transferring calls to the main
thread with Q_EMIT signals is that if the code that should run in the
main thread needs SolarMutex, then the non-main-thread must use
SolarMutexReleaser - but then the main thread will run not only the call
that is needed right now, but will potentially process all pending
events, and the other thread hasn't prepared for that.

We need the inter-thread feature of Qt::BlockingQueuedConnection and the
non-queued feature of Qt::DirectConnection, but this combination doesn't
appear to exist.

So the SolarMutexReleaser needs to go - but then the main thread does
need SolarMutex for some things, and hence we need to trick it into
believing it has SolarMutex with the m_bNoYieldLock hack.

Then it becomes apparent that the main thread may be blocked on either
Qt events, which is fine, or on the SalYieldMutex's m_aMutex, which will
never be released now.

So the main thread must never block on m_aMutex; the alternative is to
use the same approach as the osx code (and, in a somewhat different
form, the svp code), and add some condition variables on which the main
thread can block if it fails to acquire the m_aMutex immediately.

It's even possible to do this in a somewhat generic way with lambdas.

This does appear to work, but it makes the Q_EMIT approach entirely
untenable, because now the main thread will be blocked on the condition
variable and the non-main-thread will be blocked until the Qt event is
processed.

Change-Id: I6480a6b909d5ec8814b2ff10dbefb0f3686a83c7
Reviewed-on: https://gerrit.libreoffice.org/68232
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>