This reduces overhead for two reasons:

1. calls to Remove() are non-blocking

2. RunDeferred() may work on large chunks at a time, reducing the
   number of RunDeferred() calls

There's no point in passing a LightSong reference here; the callee is
interested only in the URI.

Decouples db/update/Remove.cpp from global variables.

Move global variables into the new classes.  That may allow multiple
update threads for multiple databases one day.

Detach the Song class completely from the public API, only to be used
by SimpleDatabase and the update thread.

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.

Map LogLevel::INFO to G_LOG_LEVEL_INFO, and LogLevel::DEFAULT to
G_LOG_LEVEL_MESSAGE.  Now client connect/disconnect message are only
logged on log_level "secure".

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

More preparations for multi-player support.

This is the beginning of multi-player support.  There will be support
for multiple Partition objects in one MPD process.

When adding or updating a song, we get a log message even if debug is not
enabled. It seems odd that removing a song shouldn't be done at the same log
level; otherwise looking at the log leads you to believe songs are never
removed from the library on update.
Signed-off-by: Dan McGee <dan@archlinux.org>

GMutex/GCond guarantee that the access to removed_song is protected.

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.