[5pt,8pt] Enable MESSAGE passing/ports

[RalphSteinhagen]

Clarification and Proposals for the required MESSAGE port functionality

This is to summarise the required core features and expectations MESSAGE ports within GR 4.0.

1. Streaming Ports (Syntax: In<T> in;, Out<T> out;): these are already implemented

   • handle the synchronous transmission of primitive data types (e.g., int, float, std::complex<float>) between Blocks.
   • developers must implement processOne(...) and processBulk(...) within the Block. The system triggers these functions once the specific input/output port constraints -- typically the available number of input/output sames sample -- are met
   • streams can assign unique Tags—comprising a pmtv::map_tand sample index — to distinct samples. Notably, a tag with an index of -1 signifies precedence or mandatory processing/forwarding, a feature already in place.

2. Message Ports (Syntax: MsgIn msgIn;, MsgOut msgOut;):

   • operate asynchronously, facilitating consistent 'message' exchanges between Blocks.
   • every Block<T> inherently possesses a default MsgIn msgIn; and MsgOut msgOut; Port.
   • the Graph connect API shall be the same as for the streaming ports.
   • developers may create a void processMessages(std::span in0, ...) for intercepting, manipulating, and transmitting messages. The work(..) function invokes this function if there are unprocessed messages at any input message ports.
   • execution of void processMessages(std::span in0, ...) is independent of the streaming ports’ activities or constraints.
   • all Blocks’ 'msgIn' and 'msgOut' Ports link with the superordinate (Sub)Graph and Scheduler message ports, to allow communication for user settings and error feedback through from the UI->scheduler->Graph->...->Block system layers.
   • messages on 'msgIn' that have compatible block identifiers (uniquID of the block & Block field specifications) automatically initiate changes and potentially invoke the user-defined settingsChanged(...) function, akin to Tag-induced settings procedures.
   • exception -- which should be the exception -- in user code should be intercepted on the Block<T>::work(...) level, converted into messages, and emitted on the msgOut port.

Proposed Standard Message Format (DRAFT):

struct Message {
    std::string what;
    pmtv::map_t data;
    std::source_location location;
    // Potential integration of std::stacktrace backtrace; pending widespread availability

    Message(std::string_view msg, const pmtv::map_t& data_, const std::source_location& loc = std::source_location::current() /*, std::stacktrace trace = std::stacktrace::current()*/)
        : what(msg), data(data_), location(loc) /*, backtrace(trace)*/ {}

    Message(std::string msg, pmtv::map_t&& data_, const std::source_location& loc = std::source_location::current() /*, std::stacktrace trace = std::stacktrace::current()*/)
        : what(std::move(msg)), data(std::move(data_)), location(loc) /*, backtrace(trace)*/ {}

    // Additional functionalities might follow...
};