Composer: handle replying to messages with malformed Message-Id

It's a question what would be the best place to put this check at. Moving it all
the way to the MessageComposer is tempting, but then the GUI could still show
invalid values for the "this will be marked as a reply to ..." indicators.
Moving this into the middle layers like the composer widget itself sounds just
about wrong.

If this was strictly about filtering invalid values from e.g. References, it
might even make sense to push this all the way to Message.cpp, but we have to
handle also messages whose Message-Id is simply missing -- a situaiton which is
forbidden, but could happen in real word anyway. One cannot just invent a random
Message-Id, of course.

REVIEW: 115939
RFC5322: Support stray CR and LF wherever a CRLF pair is expected in the whitespace

Thanks to Arnt for testing Trojita against the aox. It turned out that the IMAP
server sent us a Message-Id which started as "\n <actual-data>", which is not
allowed as per RFC5322.

This is a change which I do not really want to make; even the obsolete grammar
does not include this relaxed rule. However, while we were so far lucky with
strictly conformant IMAP servers, there are certainly cases out there where a
simple LF is all what we will get, and it makes a lot of sense to be able to
work under these circumstances as well.

The actual header separator is *not* affected by this; we still expect our
headers to be CRLF-terminated. We'll see if this rule needs relaxing in future.

REVIEW: 115940
Regenerated ragel after the previous commit
Add MSVC's version of alignof

Reported by PovAddictW on IRC, and later by Robin Rowe <robin@cinepaint.org> via
mail.
Check whether Qt is build with SSL support

REVIEW: 116010
move Qt ssl cmake check into Qt4 branch