[audio] pause: release pause more intuitively

# Feature request

Please consider helping users control the "paused" state in a way that more closely matches their expectations. The current `[p]pause` toggle does model the way *some* physical pause buttons work, but unfortunately doesn't map well into everyone's expectations, something I've tripped across myself, and have watched other users struggle with. It is a source of frustration for them that, even after they've read the help and understand how it works, they consistently reach for the wrong command to resume playing, since it seems counterintuitive to them.

Physical tapedecks typically had either no pause button at all, or a pause button with different behaviours depending on the tapedeck. That lack of universality of expectations for pause behaviour is at the root of the problem. In this discussion on physical tapedecks, one user describes a few different implementations:

http://www.tapeheads.net/showpost.php?s=49f24a003b049b721dad30873de619f2&p=721046&postcount=10

> My mid 80's Sanyo RD S28 cassette deck has mechanical buttons, not piano style per se, but act much like them though the heads are on a servo so they rise up that way, rather than when you push down on the play button, it raises the head mechanically. It has a separate pause button that is you press it to activate it, press it again to release, works fine for recording and playback.
>
> The Nakamichi has it, but I believe you must press play to resume recording, as is the TEAC A4300 and it too has a separate pause button, but to resume, gotta hit play.

Additionally, I recall owning at least one device, and perhaps more than one, that you'd press `pause` to pause, and could press `pause` again to unpause, but also `play` was slaved to the pause button so that if you pressed play while paused, it would *also* release the pause.

So my proposal is to implement that specific behaviour for `[p]play` with no argument instead of just showing the help, and continue to retain the `[p]pause` behaviour. That would help users who intuitively expect "pressing play should resume playing" without screwing up users who expect the current `[p]pause` toggle behaviour. This closely models those physical players that slaved the play button to release the pause button.

I understand that this may not be acceptable because `[p]play` has a different function, to enqueue a track, so you may not want to overload it with this behaviour. We have an unfortunately clash of meanings here where `[p]play` itself has departed from the conventional behaviour of the same-named button on a media device (physical or virtual). If I press the play button on a digital media player, it does not enqueue a track, but just starts playing the currently queued track instead.

On the other hand, on media streaming platforms like YouTube (I refer to the Android app when streaming to a Chromecast as a model) you're presented with a pair of controls, "Play", and "Add to queue". The Play function is represented with a standard play button symbol, and the "Add to queue" is a new symbol of their own invention which is a computer display icon with a plus sign in the middle. Both buttons enqueue the track, but the difference with play is that it inserts the track into the middle of the queue and starts playing immediately, whereas "Add to queue" adds it to the end and does not start playing. You can see in this case where the designers *have* overloaded "Play" (to start playing) and adding a track to the queue. If Google can do it, so can we. ;)