[8SP;9SP] UI: Refactor the UI to be based on runtime graph topology changes

[ivan-cukic]

The UI currently recreates the graph when something needs to
be changed, and it requires the flowgraph to be stopped for this.

Reimplement flowgraph alteration to be message-based:

• Adding blocks should be possible while the graph is runnning
  (that is, in any state of the graph)
• Connections should be performed while graph is stopped
  or paused

Keep in mind that message-based modifications are in
a request-reply pattern which means that the 'working' state
should be communicated to the user.

Should (at least fundamentally) work with local flowgraphs as well as with remote flowgraphs

[ivan-cukic]

What works:

• Implemented a 'graph model' which is only initialized via the messaging system, no direct connections to GR
• Adding new blocks is message-based
• Connecting ports is message-based, errors reported by GR are passed on to the user
• Settings changes are message-based
• Quite a few things have been reimplemented

Things that still need to be done (needed for this task, or for the future tasks of enabling hier-graphs, or adding the visual editor for the remote graphs):

• Block 'inner type' changing needs to be reimplemented
• Block RMB needs to be reimplemented
• GR reports different settings KVPs in different response messages, this needs to be unified
• GR settings' ::visible returns 'na' as the value, needs to be debugged

To be done in a future task:

• GR is missing messages for available block types (block registry / plugin loader data needs to be accessible via messages)
• Initial graph loading in OD is based on the old approach
• Currently, OD sends messages to GR via a singleton App which needs to be changed as we can have more graphs to edit at the same time (nested graphs / hier-graphs, remote graphs)
• Types that are communicated to the user are mangled, as reported by GR
• Block navigation arrows need to be reimplemented replaced by [3SP] UI: Redesign the graph traversal in the flowgraph view #202
• Initial block layout needs to be implemented (topological sort-based layouting is implemented, but not automatically performed yet)
• Code needs to be cleaned up (delete all the code from the old non-message based parts of the UI)