RioLog will stop functioning if it receives the packet header twice in a row

[Gold856]

While I was testing #786, I would start RioSender, have RioLog connect, wait a while, then restart RioSender, which would indicate the RioLog connected, but no new messages would be displayed. That PR hasn't touched the data handling, so this has just been a latent bug. The console shows a RangeError, with the error being The value of "offset" is out of range. It must be >= 0 and <= 244. Received 4384. Debugging indicated occurs at https://github.com/wpilibsuite/vscode-wpilib/blob/2027/vscode-wpilib/src/riolog/shared/message.ts#L73 and is caused by the errorCode in https://github.com/wpilibsuite/vscode-wpilib/blob/2027/vscode-wpilib/resources/testing/riosender.py#L50 being misinterpreted as a byte length, and adjusting 0x111111 to say, 0x111112 does in fact cause the read byte length to increase by one.

This only happens on reconnect; RioLog will always display the first time, and it only happens if you wait long enough (20 seconds should be overkill). And it consistently reads the errorCode as a byte length (or at least two bytes of it).

[Gold856]

Debugging a little more, it seems like there's a case where RioLog can get irrecoverably stuck. For whatever reason, the packet header gets duplicated in the internal DataStore buffer, such that you see the first six bytes be [0, 247, 11, 0, 247, 11]. The internal count remains at 247, and the frame size at 249, which seems to cause incoming data to be completely ignored as toCopy is zero.

[Gold856]

It turns out I just got really lucky with my Ctrl + C several times. After doing a few really well timed Ctrl + C, I discovered that RioLog will not recover if I hit Ctrl + C during the sleep between the first packet write and the second packet write, which explains why the packet header is duplicated (because RioLog only sees the packet header, then disconnects, then sees the packet header again).