Improve the Content-Transfer-Encoding for IMAP messages

The idea is to use the CTE of the original message if at all possible. It is not
clear, however, what is the best thing to do when the original message does not
define an allowed CTE. In this case, we just fall back to 7bit in accordance
with RFC2045's defaults.

We are, however, breaking the standard if an existing message specifies
something crazy like base64. It is not clear what would be the best thing to do
in that case. Garbage in, garbage out.

Finally, we might be completely wrong when the attached item happens to be a
standalone message with a top-level multipart -- see the comment inside. I'm
very interested in the imap-protocol ML responses; in the meanwhile, this is how
it's going to behave for now.
Prevent attaching container MIME types directly
Force wrapping as attachment for any message/rfc822 items

In my experience it makes it much clearer that a message/rfc822 directly inside
another message/rfc822 is a separate entity. If that was not the case, the
headers might confuse the user (it would surely confuse me).
coding style: rely on C++11 rules for >>

Thanks to Caspar for mentioning this in the review; there's no need not to rely
on these now that we require a C++11 compiler.