the consume mode implicitly drops the tracks from the playlist when played 'till the end (note that skipping over a track doesn't trigger the consume mode - yet?)

see GitHub issue #1

originally i tried to match the previous or next song in the playing queue after a load command if the current song was not matched. The idea is ok-ish, but the implementation was broken and become a no-op after some recent refactoring in that area.

`amused show -p' generates a listing in the form of song > current song song ... This adds an heuristic to `amused load' so that the current song can be set if it's prefixed by "> ". It's particularly useful when re-importing the state from a previous run.

IMSG_ERR needs a playlist_dropcurrent(), but otherwise is just the same as IMSG_EOF: the current song ended and we need to move forward. To unify, set current_song to NULL in playlist_dropcurrent, which make sense since right after it we're not playing anything.

this avoids the player skipping two songs on failure.

playlist.songs[play_off] is not a good representation for the current playing song after all. After a `load' command, or a flush request, the play_off changes but we're still playing the "old" song. This saves the current song in a dedicated variable that's updated upon playlist_advance and playlist_previous, thus givin a more accurate view.