Consider an electron application that uses `execFile` to run a script
that lives within the application code base:
```coffee
child_process = require 'child_process'
child_process.execFile __dirname + '/script.sh', (error) ->
throw error if error?
```
An application like this will fail when being packaged in an `asar` with
an following error:
```
Error: spawn EACCES
```
Electron overrides certain `fs` functions to make them work within an
`asar` package. In the case of `execFile`, the file to be executed is
extracted from the `asar` package into a temporary file and ran from
there.
The problem is that during the extraction, the original permissions of
the file are lost.
We workaround this by:
1. Extending `asar.stat` to return whether a file is executable or not,
which is information that's already saved in the `asar` header.
2. Setting execution permissions on the extracted file if the above
property holds true.
Fixes: https://github.com/atom/electron/issues/3512
On Windows the case sensitivity of command line switches are ignored, so
--nodeIntegraion will become --nodeintegration.
We should separate options from switches so we use "nodeIntegraion" in
options, while passing "--node-integration" in command line.
Some callbacks are stored in native resources that not managed by
JavaScript, so when those resources are destroyed the JavaScript context
may already be destroyed, and releasing callbacks then would result in
crash.
The remote method always assumes the existence of the remote object but
doesn't keep a reference to it, so if we only keep the reference of a
remote method we will get into troubles once the remote object is
garbage collected.
We should probably fix this in remote module, but since most things are
already working quite good, I'm using the work-around for now.
Fix#3139.
