[5SP,5SP] UI: Refactor flow-graph block handling

[ivan-cukic]

The Blocks in the UI should be refactored:

• YAML loading and saving should be based on the GPs built-in loader
• Blocks should be thin wrappers that only deal with the UI aspects,
  and that refer to GR blocks only by the unique identifier
• A UI black should handle different instantiations of the same
  GR Block (if it represents FFT, it should allow changing
  to FFT without)
• There should be no UI-defined blocks - everything should be
  ported to GR blocks
• All updates should go through messages

Needs considering:

• how are messages propagated when the scheduler is stopped?

pre-requisite to be completed: fair-acc/gnuradio4#210

[frankosterfeld]

Reopening, as most of this isn't done yet (and requires the messaging framework)

[frankosterfeld]

GRC loading in the UI is blocked on fair-acc/gnuradio4#287

[frankosterfeld]

Another issue with using graph-prototype's GRC serialization: When parsing a remote flow graph for the GR flowgraph service, the UI will encounter blocks it doesn't know and cannot instantiate, like the PicoScope blocks. The GP GRC load_grc would currently fail in that situation. We might have to decouple the YAML parsing from the block instantiation here.

[frankosterfeld]

Parts of this are handled in /pull/177

• local flow graph now parsed with gr::load_grc
• UI block being a thin wrapper and avoiding direct accesses of GR blocks except for drawable blocks (ImPlotSink, toolbars)
• All block implementations are without opendigitizer UI dependencies now and can be moved elsewhere if wanted

Not yet handled: Topology changes via messages.

See also #132

[RalphSteinhagen]

Thanks for finishing this. The remaining parts could perhaps be done as part of fair-acc/gnuradio4#181, or we open a new issue once/if the need arises. Will close this for now.