This PR sets the default ATOM_HOME to be relative to atom.exe, if the
following cases are true:
1. We're not in DevMode
1. We're on Windows
1. The EXE path is not in the normal installed location
This allows users to take the entire Atom folder and use it as a
"Portable" application (i.e. portableapps.com)
Previously, our Error.convertStackTrace function was provided by coffeestack,
which only works for coffee-script. This adds a dependency on 'source-map-support',
which works for any source file with inline source maps.
This also refactors the code for registering our compilers (coffee-script,
typescript, and babel) so that caching logic is shared.
In the spirit of supporting JavaScript development for Atom packages,
this adds default support for es.next transpilation support in the way
that Atom already has default support for CoffeeScript transpilation.
There are many new features in ES6+ that make JavaScript development
easier and more enjoyable, particularly in terms of support for async code.
For reference, this was a much faster way to iterate on this than running `./script/build`
each time:
```
cp /Users/mbolin/src/atom/static/index.js /Applications/Atom.app/Contents/Resources/app/static/index.js
coffee --output /Applications/Atom.app/Contents/Resources/app/src --compile /Users/mbolin/src/atom/src/esnext.coffee
```
Run the following in the console to see how warm the cache was after startup:
```
global.require('../src/esnext/').getCacheHits()
global.require('../src/esnext/').getCacheMisses()
```
This ensures the drive letter is consistent on Windows for when
package paths are compared to the resources path to determine
whether to use the metadata cache for a bundled package.
Closes#3932
Do it previously in window-bootstrap caused several things to not be
included such as requiring coffee script and atom shell modules.
Now it is a much more accurate representation of on load time.
