Fix endless sync loop with some remote iCal sources

The sync in SingleFileResource implementations (iCal, vCard and MBox
resources) is implemented in a little strange way for remote files:

1) Akonadi (or someone) requests sync of the resource's collection
2) The resource starts a download of the new file
3) In the meantime, it syncs content of the current version of
   the file with Akonadi
4) When the file is downloaded, hash of the file is compared with
   previous hash and if they differ, goto 1

Some remote sources (e.g. Google Calendar) generate the iCal on-demand
and as such the file always contains a different DTSTAMP. Thus, whenever
the iCal resource completes the download, the hash will always differ
compared to the previous one, and so it will again re-schedule sync
over and over. While the data are actually available in Akonadi and
to the user, it causes a high CPU load as the iCal is constantly being
re-parsed, Akonadi database update, the Indexing agent is triggered
over and over again. And the bigger the calendar, the worse it is.

This fix changes the behavior by downloading the file, running the
parser (iCal/vCard/mbox/...) and after that performing a regular
sync, so basically:

1) Akonadi (or someone) requests sync of the resource's collection
2) The resource starts a download of the new file
3) When the file is downloaded, the resource syncs the content of the
   file with Akonadi.

I have opted for using QPromise+QFuture combo to perform the async
chaining of download->sync. It's the only solution that requires the
last amount of code refactoring and reorganization in order to properly
sequence the operations. This would be the perfect place for using
coroutines, but I don't want to introduce coroutines as part of a
regular bugfix. I might do an experimental port at some point later.

BUG: 384309
FIXED-IN: 24.02.1