Previously, we were sending the key attached as long as the contact
hasn't replied back. But with new key replace scenarios, we need to updated
the contact keyring with the new key.

We can implement autocrypt or similar in the future, but for now, let's
send the key attached on every email.

When content-type was set in the message headers instead of the
MIMEPart (e.g. when not using MIMEParts in the message) bitmask would
ignore it and add the content as text/plain. This caused problems with
Nylas.

To fix this, if the message is not Multipart I'm keeping the
assumption that everything is going to have the maintype of "text" but
copying the subtype from the original message.

This also decodes the original message's payload before attaching the
old content to the new message to make up for the loss of encoding
information.

-Resolves: #9064

We were encoding some parts as base64 and others with our manual
encoders. Let's not do base64 and use the email standard library
encoders instead.

- Resolves: #8957

I changed most of the logger statements to use a class attribute, in
this way it's easier to identify which class it's logging them.

in some cases I leave a module-level logger, when we're either using
functions or when the module it's too small.

at the same time I did a general review and cleanup of the logging
statements.

a bit hacky and all, but this should launch the service
and allow interacting from the default site (localhost:9090).

this is the first example of a pyqt-js bridge, it's an interesting
mechanism that we can use more in the future.

no efforts made so far in authenticating the app.

this looks like a careless migration to twisted failures.
who knows how long this was like this, this should be covered by tests.