added checksum escape

[alxwk]

I found an interesting thing in the protocol (maybe it was just added recently).

If the final checksum byte of a message equals 0x7e, it needs to be "escaped" by doubling it.

Examples I've captured with Wireshark under Win10:

84831   38.381411       host    3.18.2  39      7e063f171a013d3f00007e7e
[...]
100486  44.386961       host    3.18.2  50      7e063f171a013d3f00007e7e7e062d13f53100000000f7
[...]
165201  65.711808       3.18.2  host    52              7e078e2100000b000000327e7e7e078e910000060000001dd4

So, for example, in the last reply the device 0x12 answers with the message having the checksum==0x7e, it gets doubled, and then follows the next message from the device 0x19, resulting in three 0x7e in a row.

(I learned about it the hard way — as I'm making a telemetry utility, I accidentally stumbled upon the telemetry combination resulting in a message having this checksum, and after sending it as is, without doubling, the wheel started to behave strange, RPM LEDs falling into some sort of "idle mode". Took me a couple of days to figure it. Honestly, it's not the brightest handling of a communication protocol by Moza developers, but oh well...)

[Lawstorant]

Hmm, I need to test this a bunch more as it doesn't make 100% sense to do this. The header already contains the message length so we easily know when 0x7e is a start of a message or just part of it.

[Lawstorant]

I found a few settings that create such checksum but try as I might, it always works properly.

[alxwk]

Well, in a case of boxflat as an utility which only uses the serial for settings change once in a while, it may be not much important. In my case of a telemetry app with a constant serial exchange any discrepancy can be noticed pretty quickly. I filled this PR mostly just as a heads-up, if someone hits the same situation as I did. I agree that such "escaping" is not necessary for any sensible handling of a serial protocol, but apparently Moza developers (or a LLM they use) think otherwise.