Split controller OSC off from SuperDirt handshake OSC (Redux for 1.9)

[matthewkaney]

This cherry-picks the changes in #1027 into the 1.9-dev branch, since they aren't specifically related to 2.0 and would be nice to include in 1.9.5 (the most practical benefit is that this removes the "Tidal can't connect to SuperDirt without a control port" error state that occasionally scares new users).

Marking this as a draft until I test this locally and verify that everything works. This duplicates an already-merged PR, so it should be fine, but it would be awesome if anyone wants to give it a quick look over to make sure there's nothing questionable happening.

[matthewkaney]

I'm holding this off until 1.10 so it can be incorporated into #1059

[matthewkaney]

Did some testing and it looks like this is all working on my end. To recap: SuperDirt handshakes/bus mappings are handled by individual targets, rather than by the stream. This means that each handshake occurs on a separate UDP port, and SuperDirt targets no longer use the Tidal control listener port for sending messages.

Fixes #1030 as well—a bug where the control bus mappings weren't actually being properly used to address bus messages (and therefore bus params wouldn't work if SuperDirt allocated a different block control buses than 0-n)

In general, this is part of a broader effort to separate out different pieces of stream functionality (ie, consolidate the listener logic, consolidate SuperDirt-specific features, etc). I know @polymorphicengine has been thinking along these lines, so let me know if you have any thoughts!

[polymorphicengine]

i think this is looking good!
are you also planning to move into the direction of the extendable OSC controller? (#982)

i mean it is actually pretty much there, we only need to abstract over the act function inside ctrlResponder so people can extend it like

act' :: O.Message -> Stream -> IO ()
act' matchingMessage str = customAction str
act' m str = defaultAct m str

[matthewkaney]

are you also planning to move into the direction of the extendable OSC controller?

Yes, though I think in a separate PR. My (maybe controversial) thought is that the Stream object shouldn't own the controller/listener at all, since the listener is just a wrapper around functions that the Stream object exposes. Or else we move to a point where all of the relevant code is split across a bunch of small logical components (a clock, a listener, some targets, a playmap abstraction) and Stream is just a set of MVars that holds together a default (but entirely optional) Tidal setup.