Add RtMidi back-end

hile from IRC is looking at doing this as part of supporting hot-plugging.

---
Daniel Schürmann:

I have made a short review of the RtMidi code, without additional test. (So maybe I am totaly wrong) Here are my results:

I think RtMidi is not suitable for Mixxx because of the following reasons:

1. The ALSA interface is implemented by a polling thread which is scheduled every ~1 ms. This was identified as too often. (See Bug #990992)
2. The Windows, Mac and Jack interface is actually implemented as a callback routine from an thread initiated with some init functions. I don't know if they are also just polling threads or are waked by the kernel but in any case they will fire in a for Mixxx unpredictable moment. For me it is better to let Mixxx itself control when Midi data should be processed.
3. At least in case of Jack the callback is fired with realtime priority. I do not know if this is the same thread as the audio callback thread, but in general it is enough to have only one periodical RT thread in mixxx. We may achieve the same results, if we do the midi polling within the audio thread. But I dont think this is required because we do not process a audio Midi stream, just Midi control commands.
---
Sean Pappalardo:
Do these still stand for v3.0.0 of RtMidi? There is the option of having input messages queued instead of called back, then we use getMessage() to retrieve them. This eliminates the concern in point #2 at least.
For point #3, real-time priority is desirable for controllers with spinning platters as they send tons of data and any lag causes a warble in playback. The Controller subsystem creates a separate thread for each ControllerEngine.