When the decoder is still starting up while we handle a SEEK, finish
the "player SEEK" immediately and re-enter the player loop, being able
to handle commands (and even cancel the pending seek).

This is the first part in a series of patches to solve the "blocking
input blocks decoder, blocks player, blocks the main thread" problem.
There are many other blocking code locations left, and the main thread
isn't non-blocking either because it waits for "seeking" to become
false.

Reduces main thread contention.  Avoids blocking the main thread in
"status" commands.

This eliminates some overhead, because the compiler doesn't need to
consider these functions throwing.

Eliminate a dependency from MultipleOutputs on PlayerControl.

Obsoletes the same variable from AudioConfig.cxx.

Prepare full C++ exception support in the player thread.

Fix regression by commit 45f6129a

See http://bugs.musicpd.org/view.php?id=4477

Instead of stopping playback completely, only CANCEL the queued song
if necessary, and use the SEEK command to play the selected song.
SEEK will take care for current playback state.

Assigning nullptr to next_song may disrupt the player thread and
render undefined behavior.

Another big chunk of code for multi-player support.

From now on, struct Song will be used by the database only, and
DetachedSong will be used by everybody else.  DetachedSong is easier
to use, but Song has lower overhead.

Finally restores an important feature that has been broken for several
months when the PlayerThread started working with Song copies instead
of pointers to the Queue's Song instances (commit e96779de).