Add support for two UART connections

[daveythacher]

This will require dividing the frame buffer into two sections. I will need to think about this some more later on. This has a few compatibility issues.

[daveythacher]

The issue I have with this is the 2 to 1 relationship of this. I would need to create a background thread that submits the front buffer or build a command protocol. The background thread would create tearing. The command protocol creates blocking and forces reliable transportation without tearing.

I would end up with two serial algorithms running as coroutines. This would also mean more interrupts. I may also have to change the interface to the matrix algorithms.

I think the serial algorithms should stay monolithic. Faster IO protocols are possible with PIO, however this will require an external bridge. This may be pointless, however this may be the cleanest way to go.

Unless I implement a bonded mode. I think I could use pointers to keep this clean with the existing APIs. In fact I may be able to make this approach work with the new version of the serial algorithm I am considering. The only difference is there will be second channel with frame data. If I keep them monolithic then one governs the other. The host will have to obey this.

[daveythacher]

Note the protocol in #20 is somewhat blocking and does not work with out of order frames. In fact it actually intentionally blocks the problem by allowing only one frame to be in flight. The RP2040 does not have the memory for this, even if it wanted to try this with buffers. This would be closer to USB than Ethernet. This would be like a hybrid of bulk and isochronous? I am not sure TCP or bulk is what I am looking for here.

[daveythacher]

This may not be required anymore due to #7. Trying to decide if it is worth the complexity.

[daveythacher]

Decided to remove.