[performance] Schedule resolveAddress immediately

resolveAddress requests are done with one query at a time, in
order to correlate the results with the looked-up addresses.
Doing them sequentially via UpdateRequest events added a lot
of overhead in the form of coordination between threads.

This commit creates a dedicated QContactFetchRequest for each
resolveAddress call, so that the events for starting them can
arrive all together in the backend thread and the events
announcing the results can arrive all together in the UI thread.
They will still be processed sequentially, but this change cuts
out the delay between finishing one request and starting the next.

In tests with 10k contacts and a recent contacts list with limit=20,
this reduced the resolve time from 1s to 0.3s.
[performance] Tweak the addressResolve requests for better query plan

The qtcontacts-sqlite backend was generating queries like

SELECT Contacts.contactId
  FROM Contacts
 WHERE Contacts.contactId > 2
   AND Contacts.syncTarget = 'aggregate'
   AND Contacts.isDeactivated = 0
   AND Contacts.contactId IN (
           SELECT contactId FROM PhoneNumbers
            WHERE normalizedNumber = '0123456789')

which results in a full scan of the Contacts table,
with a subquery for each id. The sqlite query planner
does not promote subqueries from WHERE clauses.

Adding a sorting requirement on the relevant detail
changes the query to something like this: