[Downloads] Use a queued connection for the download manager everywhere

[bugwelle]

Fix #1073

---

I previously assumed that we had a threading issue. But this is not
the case because connect() calls methods of DownloadManager only in one
thread, DownloadManager's thread.
But I forgot that signals (e.g. "emit sigFinished") call their slots
immediately by default. This means we could end up in inconsistent
states because member variables are changed while we are still inside a
method that depends on them or has a previous state. For example:

 addDownload()
   startNextDownload();
    on finished: downloadFinished()
      emit sigDownloadFinished(elem);
        some slot calls addDownload, m_currentDownloadElement changes
      emit sigElemDownloaded(elem);
        may emit wrong element

To avoid this, I've adapted all places where a connect() to this
download manager is used. Those places now all used a queued
connection.

But to be more robust, we should refactor this class and get rid of
all member variables that may change state.
Also, this would allow parallel downloads.

[bugwelle]

I'm merging this. While it doesn't fix the crash, it is better code style.