This fixes a deadlock bug introduced by 18076ac9.  After all, the
second Cond was necessary.

The problem: two threads can wait for a signal at the same time.  The
player thread waits for the output thread to finish playback.  The
main thread waits for the player thread to complete a command.  The
output thread finishes playback, and sends a signal, which
unfortunately does not wake up the player thread, but the main
thread.  The main thread sees that the command is still not finished,
and waits again.  The signal is lost forever, and MPD is deadlocked.

The main_cond variable was completely unnecessary.  The pc.cond object
can be used for both main->pc and pc->main.

Don't let the "client" pass its own GCond.  This was not used
consistently.

Fixes build problems with mingw32.

This commit reimplements the core of the "single" mode.  Instead of
doing the detection in the playlist code from the outside, it is moved
to the player thread, which gets a new option called "border_pause".
It will now pause playback exactly at the beginning of the new song,
making the feature more reliable.

Now that the player thread knows what will happen, it can suppress
cross-fading.

Fixes mantis tickets 0003055 and 0003166.

Make sure the player "owns" the next_song object, so nobody else can
free it.

Rewrite of the pc_get_error_message() function, now using a GError
object instead of the complicated "errored_song" attribute.

Now that the player thread can handle SEEK commands while not (yet)
playing, we can remove the "pc.state" check from pc_seek().

These fixes were mostly generated with `codespell' [0] and manually
reviewed.

[0] http://git.profusion.mobi/cgit.cgi/lucas/codespell/

Remove the decoder dependency on player_control.  All player_control
was needed for is to signal the player thread, and we can do that with
a simple GCond as well.

Allocate a player_control object where needed, and pass it around.
Each "client" object is associated with a "player_control" instance.

This prepares multi-player support.

Race condition fix.

Adds mixrampdb and mixrampdelay commands.  Reads MIXRAP_START and
MIXRAMP_END tags from FLAC files and overlaps instead of crossfading.

After we've been hit by Large File Support problems several times in
the past week (which only occur on 32 bit platforms, which I don't
have), this is yet another attempt to fix the issue.

The assertion shouldn't access player_control.next_song without
locking it.

Don't wake up the target thread in every iteration of the wait() loop.
Waking it up once, right after the command has been set, must be
enough.

These parameters must be protected with a mutex, too.  Wrap everything
inside player_lock()/player_unlock(), and use player_command_locked()
instead of player_command().

Allocate a decoder_control object where needed, and pass it around.
This will allow more than one decoder thread one day.

Use GMutex/GCond instead of the notify library.  Manually lock the
player_control object before accessing the protected attributes.  Use
the GCond object to notify the player thread and the main thread.

With these methods, an output plugin can allocate some global
resources only if it is actually enabled.  The method enable() is
called after daemonization, which allows for more sophisticated
resource allocation during that method.

Tracking the "elapsed" time from the chunks which we have sent to the
output pipe is very imprecise: since we have implemented the music
pipe, we're sending large number of chunks at once, giving the
"elapsed" time stamp a resolution of usually more than a second.

This patch changes the source of this information to the outputs.  If
a chunk has been played by all outputs, the "elapsed" time stamp is
updated.

The new command PLAYER_COMMAND_REFRESH makes the player thread update
its status information: it tells the outputs to update the chunk time
stamp.  After that, player_control.elapsed_time is current.

Sending PLAYER_COMMAND_STOP followed by PLAYER_COMMAND_QUEUE does the
same.  PLAYER_COMMAND_PLAY is redundant.

After some of the commands, the player thread must have reset the
pc.next_song attribute.