Gui: SettingsDialog: For SMTP and SSMTP methods enable Save Outgoing Mail checkbox

When user click on IMAP SENDMAIL method, Trojita automatically check
Save Outgoing Mail checkbox and disable it. When user again select SMTP
method Trojita should re-enable this checkbox and allow user to uncheck
this checkbox.

REVIEW: 111495
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