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 regexp does not seem to exist in latest mimefuncs for whiteout-io or in email master. It would be good to get some background on why it is needed, and why it was used instead of porting over the master similar code. My main concern is test coverage for it, and the `[^\s\w\?!*=+-]` part is new to me, what it is trying to match. At first, I thought it was perhaps related to non-USASCII, but that is not right. Some more color commentary here might help people like me that are still new to email standards.