Coding style: remove extra whitespace
Refactoring: move the string -> index discovery to the utility class

This is a pretty generic task, so it makes sense to have it available form
other places as well. It will be used by the upcoming test for correct
BODYSTRUCTURE parsing and the part-id propagation.
tests: verifying RolePartId and actual item fetching

The code which handles part IDs was largely untested. This test makes it
possible to pass in the BODYSTRUCTURE and then iterate over the resulting tree
of indexes, checking that the "part ID" as used by the FETCH command and the
Trojita's internal code work reasonably.

Full rountrip via the FETCH command is performed.
tests: FETCH responses, part IDs and special columns
tests: refactoring: move shared data to a shared place
tests: verify that invalid part offsets reported by server are handled gracefully
Refactoring: use shared instances, don't repeat string literals
Fix part numbering for parts which are children of top-level multiparts

The old code would occasionally produce results like ".TEXT" which are obviously
broken.
Enable static_asserts and use them to make sure that the column counts are OK
Do not attempt fetching special parts when they are not defined

The RFC3501 is clear on saying that the TEXT and HEADER modifiers are only valid
on message/rfc822 MIME types (either the root message, or any corresponding
nested message part).

The only problem with this is that we need to support the MIME modifier on most
of the other *parts* (but not on the top-level message). This means that we would
like to have most parts with just a single special column, all top-level
messages with two extra columns, and the TreeItemPartMultipartMessage with three
such modifiers. Unfortunately, these are conflicting requirements, so we have to
live with "holes" in the special columns where most parts return an invalid
index for columns #1 and #2, while they do contain valid data in #0 and #3. The
alternative would be to abandon enums which is even more evil.

And finally, if an IMAP part does not have a part number assigned (i.e. if it is
a top-level multipart), we cannot really ask for its "special parts" with
modifiers like HEADER, TEXT or MIME.
Lazy instantiation for all special parts

All access to these members is properly guarded, so it isn't necessary to
preallocate them for all visible messages "just in case" they are needed.
GUI: silence QObject::connect errors when using SimplePartWidget on its own

REVIEW: 113294
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 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.