Improve the internal suspension mechanism to be less prone to deadlocks

[MDoerner]

As observed in issue #5053, our internal parser suspension mechanics intended to guarantee that an action is performed while no parse is running is rather prone to deadlocks. In particular, if a suspension is requested from the UI thread and cannot suspend immediately, either because another action is currently executed under suspension or a parse is running, running into the lock will block the UI thread. This is especially problematic because some actions have to be pushed to the UI thread and be waited for in the parsing process.

I see several ways we can go here.

One way is to reimplement the outer logic of the parse coordinator to use async tasks and an actual queue for parse requests and suspensions without overall locks. This will probably not be straight forward and include some hidden complexity and some gotchas.

Another possibility is to always push suspension requests onto a background thread. This will prevent blocking the UI thread but if an action needs to run on the UI thread, it will have to start a new task on the UI thread from within the suspension and wait for it.

[bclothier]

Please note also that in the case of test engine, we are pumping the message pump as well. When running on the UI thread, we do have to pump the message pump else we may end up deadlocking COM objects. I do not think we pump the message pump anywhere else.