For Android pre-5.0 compatibility (#213).

This commit also puts an instance of RemoteTagScanner into the
Instance class, and hooks it into the "add" and "addid" commands.

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.

Fixes #165.

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

That '!' accidently got lost in commit
75582d47

D'oh!

Closes #162

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.

This eliminates some overhead, because the compiler doesn't need to
consider these functions throwing.

This code (added 7 years ago with commit b233c145) has been obsoleted
by the SongLoader class (added 3 years ago).

Fix for the problem where order with priorities gets out of whack in case it's
reordered by SetRandom() while another song is currently playing.
What happens is, if some song is already playing and you have set some
priorities before switching on the random mode, and then turn the mode on, the
original code swaps position of the first song in the order (i.e., the highest
priority song) with current, so that current is 0 (which it should be). The
problem is, the "original" first song then goes to the place "current" song was
after reordering, wherever that is, instead of going after the "current" song.
This patch fixes the issue.
Also the fix makes MoveOrder() public, because why shouldn't it be, anyway.  It
certainly makes more sense than just having SwapOrders() public for some
reason.
Signed-off-by: Eugene Baklanov <miltenfiremage@gmail.com>

This commit changes a minor queue priority design to something which
makes a little bit more sense.

Previously, a song that had already been played would only be
re-enqueued if its priority had just been raised above the current
song's.  This means that if it was already above, it was not
re-enqueued.  That is a surprising behavior, because users expect a
song to be played when its priority is raised.

Now the song is always re-enqueued if its priority is raised (and
above the current song's - no matter if it has already been above
before).

 https://bugs.musicpd.org/view.php?id=4592

Failure must be indicated by returning false.