This patch fixes a regression introduced by commit aa9ffc.

The playlist.c source is currently quite hard to understand.  I have
managed to wrap my head around it, and this patch attempts to explain
it to the next guy.

The function playPlaylistIfPlayerStopped() is only called when the
player thread is stopped.  Converted that runtime check into an
assertion, and remove one indent level.

One of the previous patches removed the "random" mode check from
nextSongInPlaylist(), which caused a shuffle whenever MPD wrapped to
the first song in "repeat" mode.  Re-add that "random" check.

In playPlaylist(), the second "song==-1 && playing" check can never be
reached, because at this point, the function has already returned
(after unpausing).

All callers pass false.  Don't bother to collect that parameter.

When a song is deleted, start playing the next song immediately,
within deleteFromPlaylist().  This allows us to remove the ugly
playlist_noGoToNext flag, and the currentSongInPlaylist() function.

By calling queue_next_order() before playlist.current is invalidated
(by the deletion of a song), we get more robust results, and the code
becomes a little bit easier.  incrPlaylistCurrent() is unused now, and
can be removed.

Remove one indent level by returning diretly after the check.  This
makes the function more readable.

There were only two possible states: STOP and PLAY.  The code looks a
lot easier if we use a bool instead.  Move the variable into the
playlist struct.

The function shuffles the virtual order of songs, but does not move
them physically.  This is used in random mode.

The new function replaces playlist.c's randomizeOrder() function,
which was aware of playlist.current and playlist.queued.  The latter
is always -1 anyway, and the former as preserved by the caller, by
converting playlist.current to a position, and then back to an order
number.

Add a "changed" check to setPlaylistRepeatStatus(): when the new
repeat mode is the same as the old one, don't do anything at all.  No
more checks, no "idle" event.

When the random mode is toggled, MPD did not clear the queue.  Because
of this, MPD continued with the next (random or non-random) song
according to the previous mode.  Clear the queued song to fix that.

Merged duplicate code from queueNextSongInPlaylist().

Added several comments.

Move everything which belongs together into one common struct.  This
simplifies the implementation of several queue operations.

Attempt to untie the playlist.c knot: moved the playlist storage code
to queue.c, struct queue.

Check for current>=0, not queued>=0.

The function moveSongInPlaylist() attempted to read the position of
the current song, even if it was -1.  Check that first.  The same bug
was in shufflePlaylist().

Pass const pointers where no writes are performed.

The null plugin synchronizes the playback so it will happen in real
time.  This patch adds a configuration option which disables this: the
playback will then be as fast as possible.  This can be useful to
profile MPD.

Free memory in the finish() method to make valgrind happy.

Renamed functions and variables.

It is possible that playlist.current is reset before the TAG event
handler playlist_tag_event() is called.  Convert the assertion into a
run-time check.

Break from the loop instead of returning the function.  This calls
player_stop_decoder(), which in turn emits the PLAYLIST event.  This
allows the playlist to re-start the player.

The function player_seek_decoder() starts the decoder, but does not
check the return value of player_wait_for_decoder().

Make player_wait_for_decoder() and play_chunk() return a bool instead
of 0/-1.

Don't attempt to restart the player if it was stopped, but there were
still songs left on the playlist.  This looks like it has been a
workaround for a bug which has been fixed long time ago.

Don't assign the result of getPlayerError() to an integer.

Use g_free() consistently with g_malloc().  Don't clear the pointers
after freeing them.

The player_thread loop requests the next song from the playlist as
soon as the decoder finishes the song which is currently being played.
This is superfluous, and can lead to synchronization errors and wrong
results.  The playlist already knows when the player starts playing
the next song (player_wait_for_decoder() triggers the PLAYLIST event),
and will then trigger the scheduler to provide the next song.

Simplify some code by using config_get_positive(), instead of doing
manual parsing and validation each time.

This convenience function parses a configuration value into a positive
integer.  It aborts if parsing fails.

player_wait_for_decoder() emits the PLAYLIST event on success, remove
the duplicate PLAYLIST event in its caller.

The "TAG" event is emitted by the player thread when the current
song's tag has changed.  Split this event from "PLAYLIST" and make it
a separate callback, which is more efficient.

The "sticker" command allows clients to query or manipulate the
sticker database.  This patch implements the sub-commands "get" and
"set"; more will follow soon (enumeration), as well as extended
"lsinfo" / "playlistinfo" versions.