release v0.21.12

The check IsSeekableCurrentSong() was added by commit
44b20024 in version 0.20.19, but it
caused a regression: by doing the branch only if the current song is
seekable, the player would restart the current song if it was not
seekable, and later the initial seek would fail; but we already know
it's not seekable, and so we should fail early.

libmad has a hard-coded maximum PCM buffer size; if we make our
output_buffer just as large, we can avoid the loop, because any
possible size will fit.

These will not be used until they are initialized in SyncAndSend().

Apparently, libmad not only inserts 529 samples of silence at the
beginning of the file, but also removes them at the end.

This solves the last piece of
https://github.com/MusicPlayerDaemon/MPD/issues/601

Closes https://github.com/MusicPlayerDaemon/MPD/issues/601

libmad requires padding the input buffer with "MAD_BUFFER_GUARD" zero
bytes at the end of the file, or else it is unable to decode the last
frame.

This fixes yet another bug which prevented this plugin from decoding
the last frame, see
https://github.com/MusicPlayerDaemon/MPD/issues/601

The Xing/LAME frame indicates how many frames there are, but that
excludes the initial Xing/LAME frame.  Therefore, it should not be
counted.

This fixes an off-by-one bug which caused the last frame to be
skipped, fixing one part of
https://github.com/MusicPlayerDaemon/MPD/issues/601

Increment "current_frame" after processing the frame.

This also fixes a bug which caused the bit rate to not update after
seeking.

Broken since commit f8bfea8b

The JACK output plugin would not correctly upmix mono input files when exactly 2 output ports were configured. This fixes that.

The "end of stream" packet is not special; it contains normal data,
and thus we should pass it to OnOggPacket().

This fixes one part of https://github.com/MusicPlayerDaemon/MPD/issues/601

Applying software volume to S16 samples means several bits of
precision are lost; at 25% volume, two bits are lost.  Additionally,
dithering adds some noise.

The problem gets worse when you apply the software volume code twice:
for the software mixer volume, and again for the replay gain.  This
loses some more precision and adds even more dithering noise, which
can become audible (see
https://github.com/MusicPlayerDaemon/MPD/issues/542).

By converting everything to 24 bit, we need to shift only two bits to
the right instead of ten, losing nearly no precision, and dithering is
not needed.  Even if the output device is unable to play S24 directly,
we can convert back to S16 with only one stage of dithering.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/542