Offer the message's own format when replying (#407) (#408)

A reply opened in the format the settings ask for, whatever the message
being answered was written in, and the per-draft switch was buried in
the composer's ⋮ menu. Replying in plain text to a rich text message
throws away the formatting; replying in rich text to a plain-text one
overrides what the sender chose to write in.

When the two disagree the composer now says so above the editor -- "This
message is rich text", with a Switch button and a dismiss -- and the
draft still opens in the format the settings ask for. Switching converts
that draft only and leaves the setting alone; switching from the ⋮ menu
answers the offer too. Forwards get it as well, where the formatting
being passed on is somebody else's.

What counts as rich text is hasHtmlAlternative(), which reads the body
part's own type: `htmlBody` is derived (RFC 8621 4.1.4), so a plain-text
message has one too and its presence proves nothing.

The mock said otherwise -- it returned an empty `htmlBody` for a
plain-text message, where Stalwart 0.16.21 returns the text/plain part
in both lists. Both builders now answer as the server does, so the path
this feature depends on is exercised in development rather than only
against a real mailbox.

Two new strings, translated in all nine catalogs; the buttons reuse the
menu's existing "Switch to plain text" / "Switch to rich text". The
count falling back to English stays at 16 in every language.

Fixes #407

FEATURES.md

@@ -441,6 +441,13 @@ minimizable and maximizable; full-screen on mobile.
   code block, links (`Ctrl+K`), inline images, an emoji picker, and remove
   formatting. Tab and Shift+Tab indent inside the body.
 - **Plain text** as a per-message or default format.
+- **Answering in the format the message was written in.** Replying in plain
+  text to a rich text message, or the reverse, loses either the formatting or
+  the plain text somebody chose to write in. The composer opens in the default
+  format and offers the other one for that message, above the editor; the
+  offer is dismissible and changes no setting. Forwards too. What counts as
+  rich text is the body part's own type, not the presence of `htmlBody`, which
+  RFC 8621 derives for plain-text mail as well.
 - **Recipient chips** with autocomplete from contacts, shared address books you
   have added, the server directory and recent recipients; your own cards win a
   tie against a colleague's copy of the same person. Free-form addresses parse