expand SAY/LISTEN/REQUEST to allow "connection" style bi-directional continued signaling: CONVERSE

[zippy]

currently REQUEST/RESPOND allows a round-trip interaction by connecting the RESPONSE to the sent signal in the flux, and on the requesting end by the pending responses queue which routes signals to the right place if they are part of such a session.

The goal of this ticket is to expand this to work for persistent bi-directional sessions, so both ends can keep signals flowing inside a known context.

• evaluate if this should obviate or unify with implement REQUEST/SAY callback param #104 and the REQUEST/SAY callback
• CONVERSE instruction for creating the connection as a kind of messaging scope
• create conversation on listener's side when new signals arrive with a conversation ID
• filter LISTENER expectations by conversation ids
• conversation ids need to be inherited by execution contexts so you don't start over with every function, call...
• conversation ids should nest, i.e. when you start a conversation within a conversation, the conversation should be recorded as a child conversation, so that it can be cleaned up if the parent conversation gets COMPLETEd.
• conversation ids should be able to have a sematic identifier, specifically so that we can tag them as being part of a protocol INTERACTION
• convert message UUID to message ID which does hash chaining #132 set up hash chaining as our message ID.

[zippy]

Not so sure any more about the "TOPIC" idea. Isn't the carrier and the ASPECT good enough??