Respect a user's PYTHON or npm_config_python settings

[smashwilson]

Requirements

• Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• All new code requires tests to ensure against regressions

Description of the Change

This captures the various ways that node-gyp can find its Python executable within the entrypoint scripts and forwards them to the Python interceptor script as ATOM_APM_ORIGINAL_PYTHON. python-interceptor then execs ATOM_APM_ORIGINAL_PYTHON instead of a hardcoded "python".

Furthermore, this deals with some odd edge cases related to npm being case-insensitive when it reads npm_config_* variables from its environment. If a user had something like NPM_CONFIG_PYTHON or npm_CONFIG_node_GYP set in their environment the results would technically be undefined. 🌈

Alternate Designs

I considered using npm config set and npm config get to use npm itself for precedence rules, but npm config get reported "undefined" for unset variables instead of a blank string (and returns with a 0 status), which makes it awkward to use in scripts.

Benefits

#673 introduced a regression: apm no longer respects a user's external PYTHON or npm_config_python settings. This causes problems on systems where the default Python executable is not compatible with node-gyp. With this change, those settings are respected in a way which is consistent with the behavior of a plainnpm install.

Possible Drawbacks

This uses bash syntax pattern substitution constructs like ${..##} and ${..%%} which may not be portable to all shell environments. The shebang in our apm and npm scripts was already #!/bin/bash, though, so we should be no less portable than we were before.

Applicable Issues

Fixes #698.

[smashwilson]

... Oh yeah, I never merged this. 🙈