Introducing message port handling to blocks and graphs

[ivan-cukic]

• Added a default message port pair to gr::Block with example messages for setting properties, and lifetime control of blocks;
• Additional message port pair for gr::Graph to communicate with the blocks it owns -- used for message propagation into the graph and for exporting messages outward;
• Blocks handle the messages with (optionally) type-tagged ports -- when using named ports (or another way of port type differentiation, the processMessages handlers are chosen during compile-time and there is no need to check which port a message came on during runtime);
• Messages can be targeted to a specified unique_name. The '/' is used for separating unique_name of parent graph(s) and the block. '*' (or an empty target) is used to denote a message that is meant for all blocks;
• Since messages are arbitrary property maps, some convenience functions and definitions are provided;

[sonarcloud]

Quality Gate failed

Failed conditions

49.4% Coverage on New Code (required ≥ 80%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[RalphSteinhagen]

Thanks for the tremendous amount of work! This looks good to me and we discussed most of the remaining things online and offline. Main thing is the Graph connect API defining the edges and the fan-in, fan-out, multicast mechanics that includes the port constraints for the circular buffers as part of the connection phase.

However, these should be tackled in follow-up PRs as the focus of this PR was to make the message ports usable from an UI integration point-of-view -- which it does.

Thanks again @ivan-cukic!