An assertion failure in UpdateQueuedSong() could trigger because the
`prev` parameter is always `nullptr`, but `queued` may be set.  And in
fact, calling UpdateQueuedSong() is only necessary when the queued
song was edited, to re-queue it with the new range.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/901

Commit 13208bf5 added range support to
the `move` command, but applied the wrong offset to the `to` variable.
When the source range is before the current song, and the song thus
gets decremented by the range size, then the final destination offset
must also be decremented by the range size.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/663

Since we switched from autotools to Meson in commit
94592c14, we don't need to include
`config.h` early to properly enable large file support.  Meson passes
the required macros on the compiler command line instead of defining
them in `config.h`.

This means we can include `config.h` at any time, whenever we want to
check its macros, and there are no ordering constraints.

All DetachedSong instances should be converted to LightSong first,
which is a very cheap operation.

This enforces the "not nullptr" rule.

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).