An invalid address should result in a resolution-to-no-contact event.

Otherwise, existing resolutions may not be updated by the addition of
better matches.

When resolving an address that does not need the whole contact to
be retrieved, the fetch should include any resolvable addresses of
the contact, since address resolution is obviously in use in the
caller application.

The contact cache provided by libcontacts is intended for use by
privileged applications only.  Its functionality does not make sense
for non-privileged clients, and cannot be tested correctly when
run in non-privileged mode.

This commit adds API to allow clients to use libcontacts' standard
implementation of processPhoto() for handling PHOTO vCard properties
in their own vCard handling implementations.

For a specific set of character scripts, if a contact's first and last
names are entirely composed of that script, then that (most likely)
implies a cultural ordering for given/family name tokens that should
override the device setting.

This commit improves the SeasideImport API by allowing clients to
specify their own SeasideContactBuilder implementation when
converting the list of Versit documents into storage QContacts.

The SeasideContactBuilder allows the client to parametrise things
like the contact filter used to determine the subset of mergable
contacts, the merge strategy to use, and so on.

Parts of commhistory (GroupManager) will send a stream of
resolve requests with many duplicates. This used to be
tolerable because requests were handled slowly in the
event loop, but now that they have higher priority it has
become a problem.

I went for the simple solution of ignoring requests that
are identical to still-active requests (same uids, same
listener, same requireComplete flag). It's not optimal (we
could combine more requests into the same backend query if we
tried), but it solves the problem without adding a lot of
bookkeeping.

This QList was not scanned when unregistering a listener, even though
it does contain listener pointers.

This change does not affect normal performance but it guards
against bad performance when there are many resolve requests.

Thanks to Matthew Vogt for the idea.

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.

startRequest was changed to give priority to ensureComplete and
addressResolve calls.

Doing multiple queries for this also meant multiple model updates,
and multiple contact field parsing on the sqlite side.

The logic for scheduling UpdateRequest events broke down when
m_contactsToAppend went empty during a fetch request; even though
more contacts were coming in through contactsAvailable, no more
UpdateRequest events would be scheduled until the whole request
was complete.

Fixed by making m_updatesPending the definitive flag for whether
there is an UpdateRequest event on the queue, rather than leaving
it on during the whole fetch request.

This change is safe because the flag was only inspected by the
requestUpdate() helper and had no side meanings. Now all
UpdateRequest event scheduling goes through requestUpdate().

We can't be certain that they exist, and if not, they cause the pre-
existing aggregation relationships to be preserved.

If a prior IsNot relationship exists, then remove it if aggregation
causes if to become invalid.

When the filter is not none, the ID query results do not apply to
the merge candidate filter.

When merging imported contacts into the existing data set, ensure that
contacts with 'bluetooth' syncTarget values are considered as potential
merge candidates.

QContactFamily and QContactGeoLocation types are now supported by the
qtcontacts-sqlite backend.

Contacts with 'bluetooth' or 'was_local' sync target values should
preserve these properties during export/import.

When sorting is not required, clear the sort property of the fetch
request; the sorting does not cause errors, but results in unnecessary
effort to process the query.

When searching for merge candidates, trim the strings used as search
tokens in case they contain problematic whitespace.

When sorting is not required, clear the sort property of the fetch
request; the sorting does not cause errors, but results in unnecessary
effort to process the query.

If a contact has no name details, but has an organization detail
including the name field, then it probably represents that organization
directly.  Prefer to use this detail as the display label in
preference to the contactable details of the contact.

Allow the configuration data to be read and updated even if the cache
has not been instantiated.

When resolving addresses, there is no significance in the difference
between empty UID and null UID; correct the tests to remove the
possibility of caller error.

Do not falsely match empty inputs to any invalid empty stored values.

In most cases, there is no benefit to validating numbers as they are
normalized, since the data has come from the system. Validation of
data already present in the system is counterproductive since it can
cause us not to process some details.

Remove typedefs used only to support qt4 and qt5 builds.