Move code for starting the part dragging into a special file
Support retrieval of mailbox name and UIDVALIDITY values for TreeItemMessage

This will come handy when we change the composer attachments to work on top of
indexes instead of raw TreeItem instances.
Switch to index-based processing when attaching IMAP parts and messages

It isn't clear to me why this code was using the tree items directly in the
first place -- I suspect it was due to the time pressure right before the thesis
deadline.
Use persistent indexes in the FullMessageCombiner

This class can potentially live for a long time, so the indexes have to be
actively guarded against unexpected changes.
Graceful handling of runtime errors for IMAP attachment drag&drop

Originally, the code would happily assert crash when fed with malicious drop
data -- it simply assumed that the mailbox will always be there, that the
UIDVALIDITY has not changed, etc. This was always true for use within Trojita,
but it's unfortunately not the case when the input comes from outside.

This patch therefore lets the constructurs of IMAP attachment items to throw
exceptions, and the existing infrastructure is now used consistently so that an
item failing to add doesn't leak memory (hopefully).
Do not pass around the IMAP part ID when dealing with attachments

There is no need to pass around this data anymore; it's already available via
the QModelIndex. Less duplicate data means smaller potential for errors.
Add accessor for isTopLevelMultipart

The IMAP model of the MIME tree is, let's say, a bit strange -- if a
message/rfc822 contains a multipart item as its root part, the child multipart
will *not* get assigned its own part number. The data are still available via
parent's .TEXT modifier, of course, but it causes all sorts of havoc in
Trojita's code. I do argue that the Trojita's model of MIME parts makes sense,
if only for providing a reasonable way for part rendering.
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 epscifies
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 itnerested 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).