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.

Wake up the PlayerThread only if it is really waiting for the decoder.
This greatly reduces the number of system calls in the DecoderThread.

Share the Mutex between the DecoderThread and the PlayerThread.  This
simplifies synchronization between the two threads and fixes a freeze
problem: while the PlayerThread waits for the DeocderThread, it cannot
answer requests from the main thread, and the main thread will block
until the DecoderThread finishes.

Prepare to migrate away from GLib.  Currently, we're still using GLib
as a backend.

Use LockSynchronousCommand() instead of SynchronousCommandLocked().
Fixes regression from commit ef663810 (dead lock due to cond_wait with
unlocked mutex).

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

These are confusing, and since MixRamp development has ceased, not
useful to anybody.

Make sure the decoder "owns" the song object, so nobody else can free
it.

decoder_is_current_song() now recognizes different instances of the
same physical song.

Replaces _current_song().

Don't read song.start_ms and song.end_ms, let the player thread manage
this logic instead.

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.

Only dc_command_wait_locked() is really being used.

dc_new() allocates the object and returns it.  dc_free() frees it
(replaces dc_deinit()).

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.

More abstraction for decoder_control.pipe.