mackie control xt and coremidi xtouch demo

[tschiemer]

Some refactoring and adding mackie control xt (or behringer x-touch specific?) functionality along with a new coreMIDI demo.

Focused on implementing features for using the device and control its surface elements. No other messages tested or touched.

Notes:

• TouchOSC does not seem to need newlines (tested on macOS with default profile https://github.com/NicoG60/TouchMCU/releases/tag/v1.1 , resolves MCU protocol for LCD does not use newline #224
• channel LCD/screen colors according to observed messages with behringer x-touch extension, compatibility with other devices currently not known.
• lcd charmap is almost identical to ASCII charmap for permissible value range so question is wether to actually have a map at all, or maybe optimize it using a lookup-table, or sanitize. X-touch hardware ignore special characters and did at least not show all the special and some particular (ex. Yen 0x5C) signs as in documented charmap. In TouchOSC special characters ( < 0x30) lead partly to funny behaviour. At the moment just using a 7-bit sanity check, also to leave freedom.
• did not observe any response of hardware device to device query as implemented in start() method of remote_control_processor, question if these queries and processor state should be kept

[tschiemer]

Just quick note before any merging were to happen, as I'll be changing a thing or two

• Missing version reply is because sysex was filtered out on the midi in port (also in the existing example)
  -> I'll fix that in the examples

• some protocol commands seem to be missing from the processor which are defined in the protocol (all leds off, reset, etc)
  -> I will add these in the most straight forward way, so at least they are available

• not quite sure how to handle device/manufacturer specific aspects like track colors. lazy approach would be to leave this initial implementation working for behringer x-touch (extender) devices as general solution and wait for other devices/protocols to pop up and adapt, which is my preferred way (also I don't have any other devices to test). maybe you have an opinion on this?

[tschiemer]

Refactoring with following design decisions:

• separated client and (possibly future) server remote control processors
• introduced new device subdirectory for device-specific implementations

From my perspective, ready for merge.