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

Fixes regression by commit 4e2a551f

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

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

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

This exception is usually thrown by class DecoderBridge, but the Opus
plugin (ab)uses it as well, so we need to catch it.

Just in case.

Prepare for a new mode which may convert to a different sample format
when applying volume, to reduce dithering.

It's not a tri-state anymore since we introduced C++ exceptions.

Fixes regression by commit 28e07e90

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

Pass only the amount of data to PcmExport::Export() when its full
output fits into the ring buffer.  Using only a part of the
PcmExport::Export() result may cause data corruption because
PcmExport's internal state may contain partial blocks which would need
to be rolled back when only some of its output data was used.

As a side effect, this fixes an assertion failure because
PcmExport::CalcInputSize() considered partial block data and could
cause Play() to return a number larger than the "size" parameter.

If snd_pcm_writei() fails, throw an error and stop playback instead
of going into an endless busy loop.