Additional check to prevent breaking keyboards

[esnunes]

Description

Problem

An issue while remapping the keyboard can bring it to a bricked state, as described in the issue #58. It looks like the issue may be related to the architecture of the host machine (arm64 apple silicon), and it is not discarded something else like encoding/locale.

Potential Solutions

• Before remapping the keyboard, the solution could generate the byte array for the default config and match it with an expected output (logic similar to a test run, but it would be executed at runtime). This step could be removed in the future, when the confidence on the solution increases. An extended version could also assert some conditions for custom remaps (as you cannot compare them to an expected output because they will vary based on the key maps), e.g. is there an expected number of bytes to be written, is it fixed or could we assert for a range?
• Similar to the solution above, it would be great to have a unit test on this, or a command to check whether the platform is generating the expected output (in case you don't have the unit test framework setup and don't want to waste time setting it up);
• Add a dry-run option to the commands that would output the bytes instead of writing them to the usb;

Notes

I'm not an experienced C/C++ developer but I can try to help. I'm considering to port the logic to Go (language I'm more familiar with) as it has less architecture dependencies and would be easier to build/distribute.

[donn]

To be clear I don't know why keyboards are getting bricked, and barring errant bit flips I don't think it has much to do with the number of bytes being written-- the way it works is that I use a "reference" remap bytevector for the keyboard in question and then modify it according to the user's configuration. This is already fairly close to how you want me to test Nudelta.

I don't have much time to work on Nudelta anymore, unfortunately. If you'd like to rewrite it in Go, I super welcome it.