This completes the bug fix commit
2065e329; if we clear "queued" then we
must clear "queued_song" as well, or another variant of the assertion
fails.

When starting playback with a specific song which does not have the
highest priority, the previous highest priority song was skipped
completely because its order was "swapped".  This commit changes to a
more expensive operation which inserts the selected song into the
order list.

This fixes a small part of #165

Applies the improvements from the previous commit to the "seek"
commands, which are also capable of switching songs.

Closes #119

Our previous use of Queue::SwapOrders() could cause surprising
results:

- sometimes, the old "current" song would be played again (if the
  newly selected song had not been played already)

- sometimes, the old "current" song would not be played again (if the
  newly selected song had already been played)

This is inconsistent, because it should not depend on whether the
newly selected song had already been played.

So instead of Queue::SwapOrders() we now use Queue::MoveOrderAfter()
and Queue::MoveOrderBefore(), which is more expensive, but also more
consistent.  It attempts to retain as much from the previous order
list as possible, and only moves the newly selected song around.

Failure must be indicated by returning false.

This is necessary to avoid an assertion failure in UpdateQueuedSong()
after LockSeek() has failed.

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.

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

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

For simpler seeking within current song.