I doesn't seem possible to post an event deterministically to the
end of the Windows message queue and then process this queued
events "in order".

PeekMessage and now even DispatchMessage process events out of
order - that's how this assert was hit. I was quite sure it would
not hit, but a simple resize proved me wrong. And the assert just
proved that all my assumptions were wrong :-(

So this gives up the whole idea of a short-circuit message queue
handling on Windows for busy processing of LO Idles and goes back
to some kind of the original "always timer" implementation. Since
the "parallel" processing of LO events after system messages
during DoYield  was dropped, this might be slower; or not.

In the end this simplifies the main loop almost to the starting
point, except for a little busy loop, if we wait for an Idle event
timer - not so busy acually, as we just switch to another local
thread, which hopefully is our idle timer waiting to fire.
A short-circuit with a little detour.

Change-Id: Id63a2a9e2a3b1501ad50a2c6f308a36efe55e68f