Bug 1087811 - [email] update minification step to work with newer ES6-ish features

Introduces `build/esomin.js`, to handle a dir or file-based optimization of .js files. By default, it supports an AST-based minification via esprima/escodegen, but a different minification function can be used if desired, and a comment on how to use jsmin is in the docs for that file.

Email and calendar were updated to use this minification approach, which should allow them to use some ES6 features.

Before this change, email used uglify2, as provided by r.js, but uglify2 lags in support for these newer features. While the minification was greater with uglify2, it is only a 10% loss with this new approach, and it opens up email to consume shared components that may use newer features like template strings (like possibly the newer gaia custom elements).

For calendar, it got (and still gets) the jsmin treatment on script src files mentioned in its index.html, but it was not getting any other minification on the other files dynamically loaded by the AMD loader, or for the script loaded into the worker. Now, if GAIA_OPTIMIZE=1 is passed in the build (which happens for production/device builds), this extra minification happens.

Calender could opt for the jsmin path for all files. The downside is that jsmin removes line breaks, so it creates more of a challenge when trying to debug or when getting error stack traces. When I tried the "all jsmin" route, these were the application.zip file sizes, in bytes:

    723,425 master
    604,264 this branch, astMinify
    575,637 this branch, jsmin

If this new method cannot minify the file due to malformed JS or an unsupported AST structure, the file is just skipped. So the failure case is just that a file may end up larger than it would otherwise, but will still work, and the build will continue without interruption. A log message is emitted though, in case the developer wants to track down the minification problem.
Some tensions to consider:

* the AST-based minification by esomin means only supported ES6 features of the AST tools can be used, which likely be behind whatever is in latest SpiderMonkey. And there are a couple of things in SpiderMonkey that are not exactly spec compliant yet.
* Passing in a jsmin-based function to esomin means that the minification is not AST based, but line returns are no longer kept, making debugging of optimized code harder to do. For email, we have wanted to keep those, and are willing to live with feature limitations of the AST minifier. Plus, over time, I expect we can get some variable mangling, maybe even dead code branch removal once the AST tools align on a common AST.

The trick is too that most devs probably do not test with GAIA_OPTIMIZE=1, so problems with unsupported AST features will not be immediately obvious, nor the "no line returns if using jsmin" tradeoff.

Perhaps it could end up like this for a common change:

* By default, esomin is used to traverse the build directory using jsmin as the minifier, since if the project is relying on the default gaia_build_defer_index.js behavior, it is using jsmin for that anyway.
* Projects can opt out of this by indicating they already handled the minification. There used to be a gaia_build.json that would have some declarative config for use in a build, but that was removed a while ago. Maybe it is enough to just see if the app has a build/build.js, and if so, then it is their responsibility to minify.

If that seems good, then I can file a separate bug to track that change. Might be good to have this changeset in the tree for a bit to see how it works out for a few cycles too.