Support request / response scheme

[spoenemann]

From theia-ide/sprotty#218:

We have several actions that appear in request / response pairs:

• RequestModelAction / SetModelAction
• RequestPopupModelAction / SetPopupModelAction
• RequestBoundsAction / SetBoundsAction
• RequestExportSvgAction / ExportSvgAction

We should add a mechanism that allows to match a response to a corresponding request. This is necessary in case multiple actions of the same kind are fired at the same time.

[JanKoehnlein]

Some thought and results of internal discussions:

• This is of course similar to notifications vs requests in JSON-RPC.
• We have to match requests with their responses.
• Question: Should the ActionDispatcher block (defer incoming actions) as it waits for a response? We have already a simple blocking mechanism in the ActionDispatcher that should be revised as well.
• We should not cut the API such that a promise can be awaited where actions are dispatched, as this happens usually within a transaction. Continuing the control flow when the promise resolves but after the transaction has already finished should be avoided.
• A common case is that I want to dispatch a CenterAction after some action causing a model change. Due to the model change, we're likely to produce RequestBounds, ComputedBounds or even LayoutActions that have to be executed before the CenterAction.
• What happens to actions that cause a change of the DOM? Should their promise resolve before the deferred rendering has happened? Likely not.

[spoenemann]

This might help for solving #85: implement "model inspection" requests such as GetSelectionAction, which results in a matching response that contains the currently selected model element ids.