Replace rtl_fm with UDP or REST implementation

[wizardishungry]

rtl_udp or rtl_fm_python allow us to control an rtl_fm process over a UDP or TCP control socket respectively. Leaning towards the UDP implementation as it should be simpler.

Advantages

• Easily allows multi dongle setups; right now rtl_fm has statically allocated structures that need to be converted to be per device. I'm not in the business of refactoring rtl_fm.
• removes threading code; we'll just select on a file handle streaming PCM.
• Additional tuning parameters:
  • controllable with CV: gain, squelch, decoding mode (FM,AM,USB,LSB)
  • controllable with panel control: auto gain enable
  • will require rtl_fm restart (use context menu): dongle index
• Removes hacked rtl_fm code from repository; will be included as a submodule & packaged with zip.
• potentially add other fm decoding modules to the mix
  • redsea - Radio Data Service display
  • darc2json - more radio data
  • stereodemux - STEREO AUDIO
• Moves all that I/O out of Rack
• rtl_fm crashes won't crash Rack
• Allows BSD license for entire module and maintains my copyright, so I can distribute this module linked against my proprietary code for the Pulsum Quadratum module pack.
• Circumvents GPL licensing issues for adding panel graphics copyrighted by me. I will use a license similar to the Fundamental SVGs. See VCVRack/Rack#854
• Fixes static linking issue on Linux #26

Disadvantages

• Neither implementation has a network transport for PCM data, so we won't be able to add an option to stream from a remote dongle.
• Potential increase in latency for both PCM data and tuning. Tuning granularity over time is bad right now; you may only tune ~10 times a second. I believe I also modified the rtl_fm sources to not clear the audio buffer after a tuning event. We may need to include a patch to the rtl_fm implementation to replicate this behavior.