Fix QT_NO_CAST_{FROM,TO}_ASCII in libCommon
Remove unused function which is wrong anyway
Fix strings vs. byte arrays in SMTP submission
Distinguish between a string and the byte array
Fix forgotten QObject::tr()
Add missing QObject::tr() call for localization
Fix QT_NO_CAST_{FROM,TO}_ASCII in libMSA
tests: Request message metadata before we attempt to attach any part in composer

This will be used in a later commit when the code attaches a complete message.
Add tests for attaching complete messages, not just message parts

The biggest reason for this is to make sure that I do not break the CATENATE
URLs when I fix the QT_NO_CAST_FROM_ASCII thing in the next commit.
Composer: simplify the way headers are generated

Using QByteArray::append wasn't a terribly good idea in the first place. I
wonder why I did it so back then. Well:

    commit 30b527c68e5bdb192e91e6a43f847209a0f4c675
    Author: Jan Kundrát <jkt@gentoo.org>
    Date:   Wed May 6 02:03:15 2009 +0200

        wip: this sent the very first message :)

I believe that that explains a lot.
Fix QT_NO_CAST_{FROM,TO}_ASCII in libUiUtils
Fix QT_NO_CAST_{FROM,TO}_ASCII in libComposer
Enable QT_NO_CAST_{FROM,TO}_ASCII where it is already safe
Towards strings-vs-bytearray correctness in libImap
Fix string-vs-bytearray in encode/decodeImapFolderName
Pretty straightforward string-vs-bytearray fixes
string-vs-bytearray

Yes, this changes the return value, but this particular part was only useful
when debugging anyway.
GenUrlAuthTask: switch to working with QByteArray
string-vs-bytearray: mostly trivial changes
Use QByteArray for various IMAP-related paths

Using QString doesn't really make sense in this context because the data we
operate on are absolutely not Unicode.

The change is rather intrusive, though, so I hope that I managed to catch all of
the instances where the drag-and-drop operated on QStrings. Maybe we should
switch to regular URLs here.