This busy-lock happens, because user messages have a higher priority
then some system messages. What happens:

1. The main system loop picks up the LO scheduler
2. The idle worker (IW) is started
3. IW checks using AnyInput( VCL_INPUT_ANY ) for system events
4. A system event is found
5. The LO scheduler gets posted again
6. The main system loop picks up the LO scheduler instead of the
   system message => goto 2

Normally it's suggested to use WM_TIMER in this case, as these messages
are supposed to have the lowest priority. But this doesn't work, if
you use PostMessage to generate them and SetTimer doesn't accept a
0ms timeout. At least PeakMessage also picks up the WM_TIMER message
before the system message, probably because PostMessage is somehow
related to the threads queue - who knows.

In the end this implements a manual, low priority event, which is checked
at the end of the ImplSalYield function. It just runs, if there is
nothing else to do. We still have to emit the timer callback event,
as ImplSalYield may wait in GetMessage, but wParam now indicates, if
it's a wakeup and can be ignored. We use the same event, so it's
easier to filter.

Thanks to Mike Kaganski for the missing information and ideas for the
final implementation.

Change-Id: Ib8e4f214ab8d3731d5594d68f38f46982c2eb36d
Reviewed-on: https://gerrit.libreoffice.org/40190Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>