SqlScanResultProcessor: don't accidentally delete tracks, defensive rewrite

This fixes data-loss that I can trigger every time by toggling "Local
Files & USB Mass Storage Backend" in Config -> Plugins, restarting
Amarok and triggering collection update / rescan.

In theory, more things such as cloning changing disk could trigger this
problem, from SqlScanResultProcessor::deleteDeletedDirectories() comment:

We need to match directories by their (absolute) path, otherwise following
scenario triggers statistics loss (bug 298275):

1. user relocates collection to different filesystem, but clones path structure
or toggles MassStorageDeviceHandler enabled in Config -> plugins.
2. collectionscanner knows nothings about directory ids, so it doesn't detect
any track changes and emits a bunch of skipped (unchanged) dirs with no
tracks.
3. SqlRegistry::getDirectory() called there from returns different directory id
then in past.
4. deleteDeletedDirectories() is called, and if it operates on directory ids,
it happily removes _all_ directories, taking tracks with it.
5. Tracks disappear from the UI until full rescan, stats, lyrics, labels are
lost forever.

Also add a handful of asserts, ScanResultProcessor is very complicated
and small error or corner-case in logic may result in horrible data
losses.

Reporters of linked bugs, please try to reproduce your data-loss with
this patch applied and report back in both cases. In negative case,
please reopen and attach full updated amarok --debug log.

After this patch, only (statistics, lyrics and labels)-loss operations
should be:
a) moving track out of mounted collection folders [by design]
b) changing both metadata and url from outside of a track not tagged
by amarok_afttagger [we can do nothing about this]


FIXED-IN: 2.6