Python command line options not propagated by setup.py

This issue affects use cases where PySide2 is being built from source using a Python 2.x compiler (e.g. 2.7.16) on a system where:

• other versions of Python are present
• the PYTHONHOME and/or PYTHONPATH system variables are set

When python is invoked from the command line, it will look for already-installed packages by referring to PYTHONHOME and/or PYTHONPATH if they are initialised; otherwise it will look for them in the interpreter's own default directory, typically <install_dir>/Lib on Windows or <install_dir>/lib/python2.x on Linux.

Under normal circumstances, python can be forced to ignore PYTHONHOME and PYTHONPATH and made to use only its default directory by invoking it using the '-E' command switch. This is extremely useful on systems with multiple Python versions installed but where PYTHONHOME and PYTHONPATH have been set to point to one in particular, for example a version installed by a third-party application.

However, if seeking to build PySide2 on such a system, the obvious course of action:

    python -E setup.py install -qmake=...

fails. This is because, although the setup.py script begins with the -E option and therefore takes its libraries (such as setuptools) from the default directory of the current version of Python, the script goes on to invoke setup_runner.py which starts up python sub-processes using the 'sys.executable' command. However, since these get started without the '-E' switch being propagated to them, they pick up the wrong libraries from the Python version pointed to by PYTHONHOME and PYTHONPATH and the build fails.

The workaround to this is to delete or rename PYTHONHOME and PYTHONPATH for the duration of the PySide2 build, or to run the build from a batch file or shell script which redefines them locally. However, it would be much more convenient if the '-E' command line switch used for setup.py could be propagated to these sub-processes.