See #4522 and #4521 for backstory.

Some Python packages depend on non-Python dependencies. For example, py-pillow depends on several imaging libraries. When building these Python packages, Python uses whatever compiler it was built with. Since we filter the compiler wrappers out of the Python installation, this means that we are not using Spack's compiler wrappers when installing Python packages, and hence we are not RPATHing dependencies.

Previously, we were building with:

$ python setup.py build
$ python setup.py install --prefix=...

Now, we build with:

$ python setup.py build_py
$ python setup.py build_ext --include-dirs=... --library-dirs=... --rpath=...
$ python setup.py build_clib
$ python setup.py build_scripts
$ python setup.py install --prefix=...

The build_ext phase allows us to explicitly declare what RPATH to use, solving the problem. Thanks to @mjwoods for the idea!

Additional changes included in this PR:

• Added a missing build_scripts_args function
• Default arguments like --prefix are added directly in the <phase> function
  • Previously, these arguments were added through <phase>_args. Overriding this function to try to add additional arguments would remove these default arguments
• Don't run python setup.py test anymore
  • Even when a package implements it, the PyPI tarball rarely includes the test suite, and the tests usually fail
  • Instead, we now have test and install_test methods that can be overridden
• extends implies type=('build', 'run') now
  • Previously, things like Python, R, and Perl were build/link/run dependencies, which doesn't really make much sense
  • You can now override the default type with extends('python', type=('build', 'link', 'run'))

This will likely take a while to test before it is safe to merge. I want to try building and activating every Python package in Spack before we decide to merge this. Who knows, this may even solve #3204 and numpy/numpy#8653.