Convert assertion to runtime check; this assertion could fail when the
output was closed due to an error before CLOSE arrived.

The filter can take some time to finish, even more so on a weak
machine with a saturated CPU.  By not holding the mutex during that
time, we can reduce PlayerThread latency a lot, because that thread
needs to synchronize a lot with all outputs.

Don't expose MusicChunk instances, provide higher-level access to
chunk contents.

Try harder to skip steps (reopen filter, reopen output) if the
AudioOutput is already open.

Un-protect the SharedPipeConsumer instance, and make it available in
the OutputThread only.  This gives more well-defined mutex protection.

Add another condition to Reopen() which allows keeping it open.

Make in_audio_format accessible only from within the OutputThread, and
add a new one for inter-thread communication.

Move the error logging to AudioOutput::PlayChunk().

Eliminate a dependency from MultipleOutputs on PlayerControl.

Reduce latency by stopping all AudioOutputs asynchronously.

Reduce shutdown latency by two commands per output.

Use ScopeLock to manage the lock; don't unlock after obtaining the
"really_enabled" flag; keep the same lock during EnableWait() /
DisableWait().

Without this, the pipe would run empty very often, which may result in
an xrun if the roundtrip to the PlayerThread and back takes too long.
By waking up the PlayerThread before the pipe runs empty, we make MPD
much more latency tolerant, which is a major optimization.

If we have a pending command, then the player thread is already awake.
Even if not, we'll wake it up as soon as we have finished the command.