Sound API Improvements

## Summary
This would create new APIs with the goal to make it easier, from a game dev perspective, to play sounds. This would also involve improvements to the MIDI player internals to make such things possible.
Overall goals:
* A single MIDI player, capable of playing music and sound effects simultaneously (back to 32768 Hz?)
* Support for queuing MIDI files, or even full playlist?
* A way to play a short, hard-coded note sequence without creating a whole MIDI file
* A way to play custom sounds without necessarily defining a whole timbre
* Fix the awkward way the MIDI player resets itself and needs to be unpaused whenever a new file starts
* Fix the MIDI player stopping immediately at the last event of a file, instead of letting all voices quiet down first

## Technical Spec
Some of the groundwork for this was done in #490, mainly making voices self-contained, as well as allowing a voice to be channel-less. This means it's now trivial to play sounds with any instrument, envelope, sample, or any other settings without affecting the configuration of any MIDI channels, while other sounds are playing.

It would now be technically possible to have an arbitrary number of logical MIDI "players" (not necessarily the `midiPlayer_t` struct) which all share a single synthesizer component but have their own channel state. This should be significantly cheaper than just having two entire MIDI players, one of which might be unused almost all the time, but it's also more flexible. There are a couple major options for how this could work:

1. Change the MIDI player to have an arbitrary number of channel states (e.g. in a linked list), each of which is paired with a file. This would allow playing two or maybe more overlapping MIDI files, regardless of their complexity. This would be the most flexible option, but honestly probably not all that useful to us, since mostly we'd play background music, sound effects, and maybe a short jingle. It would also be more susceptible to running out of memory than the current max-two-at-a-time MIDI player.
2. We have one "main" MIDI player, which can play any kind of MIDI file and has a full set of 16 channel states and can play any file. In addition to that, the same MIDI player would also have a secondary method for generating MIDI events which operates with limited or no channel state. This could be only storing single channel worth of state, or something even more restrictive like only tracking instrument changes and ignoring other settings. But limiting the state would let us more reasonably play a larger number of simpler files which is probably ideal for our use case.

As for using short non-file tracks (i.e. something similar to the old buzzer note sequences), this could be done using a simple interface in the MIDI player that holds a queued MIDI event, a time offset, a bit of state (instrument?), and a configurable method for getting events. The event method would be a union between a hardcoded buzzer-style track, a full MIDI file, maybe a custom event-generating function.