Desktop: Fix frontend message response dispatch

[timon-schelling]

Issue:
When opening desktop app with auto saved documents menu bar would not update (export entry etc. disabled) until anything else triggered a menu bar update.

Debugging result:
After document select (triggered by document load) updated the menu another (outdated) menu bar update message arrived and put the menu bar in a outdated state.
The outdated message was send before Document load, but was handled after Document load.

Main issue was that desktop handles messages that are responses for frontend messages immediately. Therefore message execution order looked something like this on desktop:

LoadDocument    - create
MenuBarUpdate 1 - create

LoadDocument - execute
 -> Response MenuBarUpdate 2 - create
 -> MenuBarUpdate 2 - execute

MenuBarUpdate 1 - execute (outdated)

Discovered that the editor handles frontend messages differently from other messages.
It requires all frontend messages to be fully processed before dispatching any resulting messages.

In the web frontend, this behavior happened implicitly because message dispatch is queued at the current end of the JavaScript execution queue.

For the desktop frontend, I added a vector to collect all responses until the entire batch of frontend messages is handled, and then dispatch them afterwards.

Also includes:

• Fix for double click travel getting ignored, double click counted even if cursor moved between clicks. Introduced in Desktop: Forward multi-clicks (double/triple/etc.-clicks) to CEF correctly #3224