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.
In IRC, talked more, and as the pull request preamble states, we should not be hitting the group scenario that concerns me. Groups normally come in like "group: ...;" so typically have the name. So better to keep this state like the upstream state, and know that we do not expect that string to show up in practice, and likely would only appear for "garbage in" data cases. We also have a long term plan to better normalize groups in bug 1097820 for the "garbage in" case.