Fix IPC code to work with --profile option

Change-Id: Ie76291e407062d872adad00d08cd01d4d811a86d
Remove dead code

The STARTTLS failure handling was changed when I rewrote the state
machine in:

  commit fa009c90ac12f984711d30c01cfaea154bb4974a
  Author: Jan Kundrát <jkt@flaska.net>
  Date:   Tue Mar 27 21:20:22 2012 +0200

    Refactor the connection establishing process

    This change brings us better IMAP compliance through requesting capabilities
    after a LOGIN.

That commit switched from using custom exceptions into using boring
ImapTask-based event signalling. A STARTTLS failure lost its special
status and was instead used as yet another error condition which results
in connection dropping.

Change-Id: Ib0d4df3bdf9a61476163931ebfa251dab21bad29
Remove unused exceptions

These are handled by emitting signals from the various *Socket class
implementations.

Change-Id: Ic90d415210249792ddacccb720d9af4afeab0144
tests: infrastructure for whole-stack item fetching

Change-Id: I27dbff15a885c2838e88a28e5fa1f8cb85e723ad
Report errors for message parts which failed to load

As far as I know, the code for TreeItem::isUnavailable has remained the
same since commit 92e0eb55695a05707b13a5b9efdb5b0c7c34ad4a. The way I
see it, it has always been buggy; if any TreeItem manages to get into
the UNAVAILABLE state, the only way of re-triggering its
download/fetch/whatever is through resetting the connection in some way.
That's the whole point of that state; it's an error, and the reason
behind that error could very well be that a connection went offline.

Now, stuff will be different when we support retrying of fetches and
when we won't rebuild the whole tree upon reconnect, but even then the
semantic of the UNAVAILABLE state seems to better match the meaning
introduced with this patch and not the former state.

Change-Id: Ie3ebe4567488a437264839b43acf13614e4072b8
Make sure our QNetworkReply instances manipulate the "finished" property

...well, actually only on Qt newer than 4.8.

Change-Id: I53a462dc42f0d7ab42a84d28f759a1499645cd96
Do not delay marking messages as read when user doesn't want a delay

Thanks to Ed Tomlinson <edtoml@gmail.com> for reporting this on IRC. The
delay is actually already implemented within the MsgListView, so
delaying stuff even further here makes little sense now.

The 200ms was some arbitrary change made yars ago:

commit 6892cd36d22d9d1e7a84852bf9a31fe61f142f50
Author: Jan Kundrát <jkt@flaska.net>
Date:   Wed May 30 21:51:01 2012 +0200

    GUI: mark visited messages as read almost instantly

Change-Id: Idbe3a15d18ac1f0c881d0dc789bff2c91f6ae13b
Merge changes I53a462dc,Ie3ebe456,I27dbff15,Ic90d4152,Ib0d4df3b

* changes:
  Make sure our QNetworkReply instances manipulate the "finished" property
  Report errors for message parts which failed to load
  tests: infrastructure for whole-stack item fetching
  Remove unused exceptions
  Remove dead code
Merge "Fix IPC code to work with --profile option"