Split keyboard support

[agausmann]

Design questions:

• How to integrate with the current keyboard component architecture?
  • Serves sort of like a scanner on the master side and an uplink on the slave. But can also (and will eventually) be used to synchronize the state of other components like backlight, as QMK does.
  • Should probably be implemented as an independent component to be used directly by the system.
• Hardware implementation
  • No guarantee about mapping of serial peripheral in most keyboard designs, and often only one pin for communication in both directions. In this case, QMK provides a transaction system similar to I2C on top of a software serial implementation.
  • QMK soft serial is a good reference for the synchronization protocol.

[agausmann]

only one pin for communication.

Turns out this is incorrect. At least for Keebio boards, both I2C pins are connected between halves. However there is no I2C slave driver for AVR yet - Rahix/avr-hal#90

[agausmann]

The interaction with const generics also makes this complicated. Each side will have pins for half of the total rows or columns (depending on how it is logically split). So a plain InputGroup/OutputGroup will have 1/2 of the total rows or columns of the end user's layout.

To fix this, there could be a Split wrapper that accepts a InputGroup<N> or OutputGroup<N> and implements InputGroup<2 * N> or OutputGroup<2 * N> respectively, with an internal flag to say which half it is (detected by the keyboard driver code). It will simply be a no-op for the pins of the other half (whose state should be reported by the MCU on the other half, via a separate SplitSync trait/driver).