Master control for playing blocks.

Here's how it works:

• Find the relevant block to play.
• Deriver generates a performable score and an inverse tempo map.
• The score is preprocessed by adding the current absolute time to it and skipping notes based on the start offset.
• Create a Transport.PlayControl to tell players when to stop, and a Transport.ActivePlayers to track the number of players still running. Start players for each kind of backend: player_thread for MIDI and im-via-MIDI, one for SC if appropriate, and an audio streaming thread if play_im_direct is enabled.
• The ActivePlayers and tempo map are passed to play_monitor_thread, which uses the tempo map to display the play position in the various blocks. It stops when it runs out of tempo map (which corresponds with running off the end of the score), or when the PlayControl goes to Stop. It's not synchronized to the play threads in any way, but of course they are both working from the same score.
• A stop from the user sets Transport.stop_player. All the players and the play_monitor_thread are polling it and will quit.
• Another thread is watching the ActivePlayers. It sent Transport.Playing to the responder when they started, and will send Transport.Stopped when they go to zero. This control's the UI's idea of whether it's playing or not. If it's playing, it still has the PlayControl, so it won't accept another play, but will accept a stop. So player threads should only exit when there's nothing left for them to cancel, so MIDI and OSC, being scheduled in advance, will hang around even after they scheduled their last message. If a player never sends Transport.player_stopped, ActivePlayers will never go to 0, and we get stuck. So they should do the stop in a finally block.

The im backend complicates things a bit. See NOTE [play-im].

repeat_at, the play speed multiplier, and the negative start adjustment also complicate things.