Refactor audio output queue

[argilo]

Fixes #495.
Fixes #497.

Here I have fixed several issues related to audio output in the C and Python CLI applications:

1. In the Python CLI, when receiving from an SDR and playing back audio on a sound card, clock drift in the sound card could eventually lead to the audio output queue becoming full. At this point, the libnrsc5 callback function would be blocked, resulting in dropped I/Q samples and loss of synchronization. The C CLI avoids this problem by dropping audio samples when the queue becomes full, and I've implemented that approach in the Python CLI as well.
2. The C CLI had an excessively large audio output queue (128 packets, or ~6 seconds). I've reduced it to 16 packets, matching the Python CLI.
3. To compensate for the (former) lack of elastic buffering in libnrsc5, the C CLI waited until the audio queue reached 8 packets before beginning audio output. This approach is no longer necessary since elastic buffering was implemented in Implement elastic buffering for audio output #399, so I have removed it.
4. In the C CLI, the push_audio_buffer function used a 100-ms timeout to avoid dropping audio output when reading from a file. This does not work correctly, as explained in Dropped audio samples when playing back recording in C CLI #495. Instead of the timeout, I've changed the code so that it blocks indefinitely while waiting for space in the output queue (if reading from an I/Q file) or aborts immediately and drops the audio packet (if receiving from an SDR).
5. In the C CLI, the push_audio_buffer function briefly unlocked its mutex while performing a memcpy. After re-locking, it was necessary to re-check the value of st->program in case it had changed. Since the memcpy should be fast, I've changed the code to leave the mutex locked.

[argilo]

To test the behaviour when the audio queue fills up, I modified the CLI apps' audio output threads to play back a small amount of extra audio samples beyond the ones arriving on the queue.

[argilo]

Prior to this change, the C CLI would drop 128 audio packets (6 seconds) if its queue filled up. Now it drops only a single packet.

[argilo]

Now that the 8-packet startup delay is gone, switching between audio subchannels using the keyboard is almost instantaneous. I'm liking that!

[TheDaChicken]

I found this to hugely improve playing iq recordings and live decoding while doing other things in the background.

The small pauses due to dropped samples were less annoying than having no audio for 6 seconds.