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 pathway uses _encodeMimeWord, but in _convertAddress, the address.name uses _encodePartialMimeWord for name normalization. Would be curious to know why. "Because email standards" is a fine answer, just calling out things that are causing questions for my logic pattern matching.