SqlScanResultProcessor: cope with non-unique uniqueid in the database

Unfortunately, the uniqueid column (or rather its index) of our urls
table is not defined as unique and unfortunately at least some code in
SqlCollection doesn't check for duplicates before inserting to the
table. This can be provoked for example by using the "Organize
Collection" functionality.

While fixing SqlCollectionLocation in short-term and making the
uniqueid index unique in long-term is probably needed, we need to cope
with existing user databases. This change is needed because
SqlScanResultProcessor identified tracks fully by their uniqueid which
resulted in unpredictable and incorrect behaviour - it for example
never removed the "old" duplicate entry in deleteDeletedTracks( int )
and sometimes found incorrect entry when importing a track in
commitTrack().

This does not solve bug 289338, but it dramatically reduces its
consequences, the (correct) duplicates are removed as soon as
collection scanner fires.

v2: the test failure spotted by Sentynel discovered a bug in patch v1,
there was an assertion that sometimes failed even for normal operation
because database updates were temporarily blocked. Fix by moving the
assertion to a place where it is valid in all cases.

CCBUG: 289338