"Binärika": byte level Erika mock

[ArchibaldBienetre]

With the current AbstractErikaMock + subclasses, we had issues in the past that the mock interface and the real interface would drift apart.

As a mitigation, we added ugly meta code to the constructors... This does not feel right / not feel python-y.
Instead, there's one level of abstraction where we cannot drift apart, that's the actual bytes as understood by the Erika device.

The BinErika implementation should

• offer a simple interface, just sending and receiving bytes / a byte stream
  • and, of course, a way to close the connection properly
• internally, it should mirror the behavior of the real device to the extent that we already support for the real Erika class
  • cf. calls of _write_byte in the Erika class in https://github.com/Chaostreff-Potsdam/erika3004/blob/master/erika/erika.py
• some bytes start commands that will require at least one more byte - this behavior should match, BinErika should expect another related byte
  • Unclear: how will the real Erika deal with invalid commands? Will there ever be such a case?
    • E.g., the left / right microstep movement needs a second byte as parameter for the number of steps to move - but there's no issue with invalid input because all values are allowed
• Hitting physical boundaries is a whole different issue - by default, the device will just stop when reaching a physical boundary (left margin / right margin) - BinErika should mirror this behavior, but deliver some output that this situation happened
• the visible rendering output of this simulation class should use curses (like already used by the other mocks)
• optional: wholly unknown commands should result in hard failure, so we know early if a feature is missing completely
• optional: Of course, should we support different type wheels, there will have to be an adjustment.
  This can be considered in the code: offer a distinction between which byte mappings are inherent, and which are type wheel-dependent.

[ArchibaldBienetre]

Implementation can happen in small steps

• let's make it work for simple left-to-write text output + newlines first
• with this as a basis, we can work in parallel for other features

[cyroxx]

Parts of what you are trying to achieve here could be tackled by (re-)implementing the DDR-ASCII codec on top of the Python codecs framework: https://docs.python.org/3/library/codecs.html
When we include support for (custom) ANSI escape sequences, we could "translate" all supported characters and control codes the Erika has.
Other thoughts:

• Different type wheels could be represented as different codecs
• The interfaces of the codecs package already allow for extension. For example, you can use/implement the error handlers strict or ignoreor you can register new ones.
• IncrementalEncoder/IncrementalDecoder are allowed to be stateful and could be used in cases like your microstep example