Use custom WaitForMultipleObjectsEx to prevent STA/COM reentrancy

[kekekeks]

We can't trust our locks otherwise: https://stackoverflow.com/questions/4540244/how-is-this-possible-onpaint-processed-while-in-waitone/4540745#4540745

[MarchingCube]

I think .Net screws us over here completely, I wonder if we actually have to handle WM_PAINT at all? And instead repaint during resize.

dotnet/runtime#12107 (comment)

[kekekeks]

WM_PAINT still has to trigger a repaint since it's being sent in certain situations when window contents are lost

[kekekeks]

Some reference material back from WinXP times

https://docs.microsoft.com/en-us/archive/blogs/cbrumme/apartments-and-pumping-in-the-clr
http://joeduffyblog.com/2008/02/27/hooking-clr-blocking-calls-with-synchronizationcontext/

[MarchingCube]

@kekekeks If I remember correctly - your plan was to add message polling for certain scenarios? Or we want to disable all messages?

[kekekeks]

I think we should disable all messages to prevent all possible reentrancy scenarios. It should be safe to do for all managed locks in Avalonia code and for all managed locks in normal (non-COM) code.

If some COM component requires message pumping inside of Monitor.Enter and can't wait for a normal GetMessage/DispatchMessage, said COM object is considered to be incompatible with common sense and, by extension, with Avalonia, and should run on a dedicated STA thread.

[MarchingCube]

LGTM.