Dual Endpoint USB about g2 HOT 2 CLOSED

A rough version of dual-endpoint USB has been pushed to the alden branch for testing. There are some shortcuts taken, but it should behave more or less according the description in the above wiki page. In short, use it like this:

1. System is idle. Nothing is connected.
2. Connect to usbserial001. This will become a ctrl+data channel
3. Connect to usbserial003. This will become the data channel, and usbserial001 will become the control channel.
4. Send controls (JSON) to ctrl (001) and Gcode to data (003). The reader will prioritize controls over data and always read and process the control if one is available before attempting to read the next gcode block.
5. If data (003) disconnects the ctrl (001) reverts to being a ctrl+data channel. 003 can be re-connected as a data channel. If ctrl (001) disconnects then both channels disconnect.

That's it.

A few observations/questions:

• There is currently no distinction at the controller (reader) level between text lines returned by the control channel and lines returned by data (gcode blocks). The controller will happily receive both and execute both. I don't think this is a problem, but people should be aware of this.
• Any command received on either channel will send its responses to the control channel. Including received data. This may or may not be a good idea. Depends on use. Also, there is no output sent to the data channel. Feedback welcome.
• One possible enhancement would be to send a connect message back up the channel that was was just connected or changed. So the first connect would send a message indicating ctrl+data, the second would send a message over both ports, one for data, the other for control. SImilar messages would be send for other state transitions. This is more complexity, but if it's useful we should discuss. Part of this might also be the ability to query a channel for it's capabilities and state.

from g2.

FYI, when running TinyG2 on Linux, the two ports appear as /dev/ttyADM0 and /dev/ttyADM1. I have not attempted to do anything on the /dev/ttyADM1 port as of yet.

from g2.