Bug 1084216 - [Email] v2.0-specific quoting fixes

In bug 1084216 on v2.0 email we are seeing a problem where mailcomposer
generates encoded MIME words inside quotes and the yahoo.co.jp server
is performing a rewrite that adds backslashes in very specific
circumstances.  (Specifically, when a sufficiently large attachment
is attached.)

This fix consists of upstream fixes directly applied to the GELAM built
libraries.  Specifically, we are taking the core of the following
commits.  And note that the mechanism I used was just to copy and paste
the modified functions wholesale from a coherent commit; I did not
attempt to do clever processing.  Specifically, we're talking about the
state at:
https://raw.githubusercontent.com/andris9/mailcomposer/f0d4edba3a7735e8ef1b31f531abfd55633ff2fd/lib/mailcomposer.js

But the individual conceptual commits are:

- a commit on the way to _encodePartialMime word in the next comit:
https://github.com/andris9/mailcomposer/commit/6c6b5210e5ed406e1c8843d0b4c9bf2afbbed782#diff-17e37864e5d9b9e5ff32cb7ac29abd65R561

- _encodePartialMimeWord which adds smarts on top of encodeMimeWord by
detecting space delimiting and encoding on a per word basis.  So it
encodes "foo bar baz" as three separate words rather than a single big
word:
https://github.com/andris9/mailcomposer/commit/f0d4edba3a7735e8ef1b31f531abfd55633ff2fd

- don't put the name in quotes if we're doing MIME word encoding:
https://github.com/andris9/mailcomposer/commit/c723d3f882031b4633d0707c8ec94a22b83bd647

- group support/refactoring.  We don't actually use this logic at all,
it was just safer/saner to copy-and-paste the refactoring that included
convertAddress.  The transform is relative straightforward and mechanical:
https://github.com/andris9/mailcomposer/commit/1dabfee6435a76dae9e3cf2a9095f90f09946ac2#diff-17e37864e5d9b9e5ff32cb7ac29abd65R407

Note that this patch does include some extra whitespace changes.  I used
emacs to do the change and my settings nuked the trailing whitespace.  I
tried fairly diligently to undo the whitespace changes but it became a
nightmare and since this is not the first time I've run into this, I've
decided we're just keeping the whitespace changes since it makes things
easier in the future too.
This line bothers me, specifically the "Recipients" hard coding. If we are asking for uplift, I would think we need a story for this on the "no new l10n strings" question. Although perhaps not if the partner is doing the uplift. 

Not sure if it is in spec, but tempting to just remove this and in the values.push below have a `address.name ? address.name + ':' : '') but I could see where mail clients might want a `name: value` structure for parsing.

I know this is also tricky since this is from the upstream lib we use, so also in a bit of an awkward position for trying to cherry pick certain changes to fit into this older code.