Maintain 'connections' to support multiple comms methods

[electricui]

Maintain 'connections' to support multiple comms methods

[Scottapotamas]

The parser working state is currently held in a structure, and the developer uart callback is passed to the library. Most remaining work is cleanup or application level logic.

• Implement a higher level structure which takes an output function pointer and holds an instance of the parser state machine for use.
• Document the declaration process, and adapt the parser input function to accept the newer structure object as the reference for the comms method
• Create internal higher level variables that allow the micro to advertise the different connection methods to the UI.
• Test on a board with multiple comms methods

[Scottapotamas]

Most software to allow this is done in the C library at a basic level (multiple comms methods can be defined and used.

From here (and some testing of hardware) we probably need to:

• Establish the idea of a "UI UUID" held on the micro at runtime so the UI can check if someone else is connected over another transport.
• Play with the idea of advertising the available transports during search or connection
• Work out how to let the developer manually publish a message on a given protocol
• Create the ability for messages to be published over "a" transport, with some concept of priority
• Test things!

[Scottapotamas]

This functionality was "in theory" working for some months, but I only just got around to testing the other day with a USB CDC connection and a hardware UART connection on the helloBoard.

As each interface is handled separately, the micro supports data coming in on any/all combinations of links at once, and all offer an equal level of functionality.

See https://www.youtube.com/watch?v=r9Qsf7isXxs

Tasks from here are mostly application level functions to allow cross-transport passthrough, and example level tasks. Those are out of scope for this issue.