[buteo-sync-plugin-caldav] Add xml files to QtC project.
Merge pull request #24 from nemomobile/addXmlTOPro

[buteo-sync-plugin-caldav] Add xml files to QtC project.
Move processing of ETags out of Report
more refactoring of Report
Let Reader automatically parse all iCalData

We will need to parse each retrived incidence anyhow to extract the
incidence UIDs.
Extract set of UIDs of all received incidences for later processing

In general, there is no correlation between the UID of an event and URI.
See, e.g. http://sabre.io/dav/building-a-caldav-client:

'The url and the UID have no meaningful relationship, so treat both
those items as separate unique identifiers.'

Thus, we should not use Reader::hrefToUid but use the real UIDs.
improve handling of deletions (without using Reader::hrefToUid)
improve processing of local modifications (do not use Reader::hrefToUid)
eliminate Reader::hrefToUid
correctly determine href for incidences which shall be deleted
make storageIncidenceList a class member of NotebookSyncAgent for later reuse
Correctly handle local deletions of incidences which were added during last sync

Incidences which have been received during the last sync and then were deleted locally
will not show up in localDeleted as their creation time is after the start time of
the last sync. Therefore, we have to go through the list of additions and add all
of them which are missing in the storage to the localDeleted list. Since
additions only holds UIDs and not incidences, make localDeleted a
QStringList.
Add URIs to locally created incidences

Otherwise these incidences will be downloaded as new incidences during
the next sync.
add missing return statement
Reload incidences sent to server in case we do not obtain an ETag

Some caldav servers, i.e. owncloud, do not return an ETag after a
successful PUT. In fact, this is not required by the specification (see
RFC 4791, section 5.3.4). This commit ensures that such incidences are
reloaded from the server using an additional multiget request.

Otherwise, any local modification to an incidence which has been sent to
the server during the last sync will be overwritten: we will see a
changed ETag on the server, and the server always wins in case of sync
conflicts ..