[qtcontacts-sqlite-extensions] Improve detail delta semantics in TWCSA

This commit ensures that detail provenance is maintained when a remote
sync results in a detail modification.
Merge pull request #134 from chriadam/fixtwcsa

[qtcontacts-sqlite-extensions] Improve detail delta semantics in TWCSA
[qtcontacts-sqlite] Connect to the correct signals on privilege fallback

In the case where we are unable to open the privileged database,
connect to the signals emitted by the nonprivileged database that
we fall back to using.
[qtcontacts-sqlite] Provide export mode for synchronization export

Some of our data is to be restricted from general access; in order to
achieve this we will create an external copy of the database, and
export appropriately sanitized data to it. Applications that are not
authorized to access the sensitive data will use the export database
via the qtcontacts-sqlite manager.

Synchronization between the two databases will be performed using
a variant of the two-way sync adaptor interface.  The difference
between this variant and the standard mode is that the export database
will not be considered the owner of data that originates within it;
that data will become owned by the primary database once it has been
imported.  Data acquired from the export database will become property
of the local constituent in the primary database, and will not be
distinguishable from data entered directly to the primary database.
Correct indentation

Indentation was intentionally left wrong in the previous commit;
otherwise the resulting diff was completely unintelligible.
[qtcontacts-sqlite] Allow details to be marked non-exportable

Non-exportable details are excluded from the aggregates reported by
fetchSyncContacts for the export sync target.
[qtcontacts-sqlite] Aggregate timestamps should be composed from constituents

The timestamp of an aggregate contact should not be updated
independently, but instead composed from the values of timestamps
in its constituent contacts.
[qtcontacts-sqlite] Suppress regeneration when the aggregate will be clobbered

During the creation of an incidental local, regenerating the aggregate
contact is wasted, as the originating copy will be used to overwrite
any changes that result.
[qtcontacts-sqlite] Fix timestamps to have millisecond resolution

QDateTimes do not seem to pass through the QSqlQuery bindings to
sqlite correctly...
[qtcontacts-sqlite] Sync adapters should not register for presence changes
[qtcontacts-sqlite] Report added contacts IDs via storeSyncContacts

Added contact IDs are typically necessary for the caller to store.
[qtcontacts-sqlite] Ignore non-data values when comparing sync details

Values such as provenance are not relevant when comparing contact
details from different origins.
[qtcontacts-sqlite] Do not use OriginMetadata for sync contact identification

This is no longer necessary since the exported ID is preserved if
an incidental sync-target contact is added to a previously exported
local contact.
Fix comment to describe current situation
[qtcontact-sqlite] Unify detail promotion logic

Provide a single function to test for the promotion of details to
aggregate.  Also, add special handling for QContactTimestamp, which
must be promoted in every operation.
Improve function naming
[qtcontacts-sqlite] Allow relevant detail types to be specified

The sync adaptor can now specify which types should be ignored in
comparison of different generations of contacts.
[qtcontacts-sqlite] Control aggregation behavior at runtime

Allow the qtcontacts-sqlite backend to be used for both aggregating
and non-aggregating databases.

Initially, the privileged database will be aggregating, and the
nonprivileged database will be non-aggregating.
[qtcontacts-sqlite] When comparing contact versions, use detail equivalence

Testing for detail superset is inappropriate, since the different
generations should not contain extraneous fields with respect to each
other. Equivalence testing is necessary to detect the removal of
fields in a new generation.
[qtcontacts-sqlite] Use contact ID rather than GUID for local/remote identification

The ID used to report a contact for remote sync is now stable. We
should now use the ID to identify the contact within sync adapters
rather than inserting this information via GUID, to avoid polluting
the proper data of the contact.