Check value of QFile::{open,flush,write}() when saving messages/attachments

To achieve this, a couple of things happened:
 * At every place where an instance of FileDownloadManager is created,
   the transferError() signal from FileDownloadManager is connected to
   the transferError() signal from MessageView.
 * The transferError() signal from MessageView is connected to the
   slotDownloadTransferError() slot from MainWindow (was
   slotDownloadMessageTransferError() first).

Thanks to Thomas and Jan for their feedback.
AttachmentView: no duplicate signals, disable downloadbuttons on download

The signals for the m_openingsManager are now connected in the
constructor, not in AttachmentView::slotOpenAttachment(). This prevents
duplicate connections being created.

While here, also disable the downloadbutton when downloading an
attachment. To implement this, I added a started() signal to
FileDownloadManager, used to indicate when the transfer starts.
Just disabling the downloadbutton in
AttachmentView::slotDownloadAttachment() causes problems when the user
clicks "Download" and then closes the File Dialog without selecting a
file. manager->downloadPart() then returns without downloading the file,
so it doesn't emit a succeeded() or transferError() signal. By creating
a started() signal, we know for sure that the downloadbutton only is
disabled when a transfer really happens. The downloadbutton will be
enabled upon success or failure.

For consistency, FileDownloadManager::downloadMessage() also emits
a started() signal when it starts downloading, although that signal is
not used anywhere.

This commit also renames slotTransferSucceeded() to
slotDeleteTemporaryFile(). I did this because slotTransferSucceeded()
seems to be a general name that can be used for both "Open directly"
and "Download", but it wasn't in the old situation. The "new"
slotTransferSucceeded() only enables the downloadbutton.

AttachmentView::slotOpenAttachment() will only download the attachment
if the temporary file does not exist yet.
rfc1951: Fix deleting another buffer in destructor

See 9eaa8510dceedc8308516b61f599c102bb1c676c

REVIEW: 111525
Gui: Window: Sync Navigation and Show Toolbar checkboxes and save window state

Navigation checkbox (right click on toolbar) doing same as Show Toolbar
checkbox (View menu). Synchronize state of both checkboxes, so user will see
always correct state of both checkboxes.

State of main toolbar (visible or invisible) is stored in trojita config file
in gui/sizeInMainWin by saveSizesAndState (e.g when changing main window layout).
So call method saveSizesAndState() when state of main toolbar is changed too.

REVIEW: 111639
Fix handling of CR characters in signature separator detection
Quoted-Printable: allow up to 76 characters per line

This conforms to the QP specification [1] -- page 22 says that 76 characters,
not including the CRLF, is OK.

[1] http://tools.ietf.org/html/rfc2045#section-6.7
format=flowed: Automatically join lines even when the sender uses CR LF line breaks
Composer: use CRLF line breaks and wrap text when producing format=flowed messages

Using CRLF line breaks is compulsory per RFC 2822 [1]. Trojita was *not*
actually broken due to sheer luck. What we sent was always wrapped in the
quoted-printable encoding which made sure that there were no stray LF or CR
characters. It came with a drawback, the actual message body came with plenty of
qp-style "=0A" escapes and it also contained excessive artificial line breaks.

After this change, the composer builds reasonably formatted messages again. The
already-existing CRLF line endings from the format=flowed pass are reused (if
possible) and even the totally undecoded message raw format is readable by mere
mortals again.

The only bit which we're doing differently is applying q-p unconditionally. RFC
3676 suggests that it should not be used for mere protecting of the trailing
spaces unless the message contains non-ASCII characters or when it's supposed to
be digitally signed. I don't particularly like the idea of adding an extra code
path for plain-ASCII messages, and given that cryptographic signatures will come
some day anyway, I prefer to apply q-p even on messages where it isn't
necessary.

Thanks to Thomas for his review.

[1] http://tools.ietf.org/html/rfc2822#section-2.3
Merge branch 'format-flowed'

REVIEW: 111842
BUG: 321462
cleanup: remove unused function declaration

This got introduced when the actual submission logic got moved to an extra file.
refactoring: move GUI for attachment removal into the view class
Composer: enable "remove attachments" only when there are some
Composer: show pretty size for the list of attachments
Composer: show pretty icons for attachments
Composer: allow inline attachments and support renaming them

It comes handy to e.g. mark a patch for an inline display. It might also be
interesting to be able to change the filename of the attachment so that it's
different than what was on-disk (an actual user suggested this).

fixes #587
Composer: make it possible to paste as a quoted text

REVIEW: 111860
Gui: treat unrecognized Content-Disposition values as "attachment"

RFC 2183, section 2.8 mandates this. One has to be careful to not treat a
missing Content-Disposition as an "attachment", though :).
QNAM: propagate errors about parts not available further up the stack
GUI: reflect uncached parts in the GUI
Let the QNAM rewrite MIME types of unsupported data in an extensible manner

The QWebView apparently doesn't check whether a MIME type "inherits" from some
supported one, like e.g. text/plain. This menas that it will refuse to render
benign stuff like a C++ source code which is marked with an text/x-csrc, etc.