- generalized and fixed to work with any key in YAML file
- simplified schema writing, as well
- add more unit tests for the config system
- Rename test/yaml.py to test/spack_yaml.py
  - Add test/yaml.pyc to ignored pyc files.

* Perform shebang fix for all files

* Fix sbang for perl scripts

Otherwise perl would look at the #! line and call sbang again, resulting
in an infinite loop.

- use --! instead of #! for patched lua scripts.

fix :  proper update of config file (before it was discarding architectures that were not the current one) fixes #774

This does several things:

- Add `sbang`: a script to run scripts with long shebang lines.
  - Documentation for `sbang` is in `bin/sbang`.

- Add an `sbang` hook that filters the `bin` directory after install
  and modifies any scripts wtih shebangs that are too long to use
  `sbang` instead.

- `sbang` is at the top level, so it should be runnable (not much we
  can do if spack itself is too deep for shebang)
  - `sbang`, when used as the interpreter, runs the *second* shebang
    line it finds in a script.
  - shoud fix issues with too long shebang paths.

imported. Other warnings should be output.

importing nose (which is also in Spack's external/ directory) outputs a warning
(since there is more than one nose package). This avoids printing the warning
to the user.

- Can't think of a better way to do this.
- The externals integration will cause spack to die in weird ways for
  users who just pull from develop.

python install and lib/spack/external have the same library installed. This
requires modifying the names of some modules in lib/spack/external in cases
where both the system python and backported features of future python versions
(i.e. after 2.6) are used (previously distinguished by "from external import X"
and "import X").

- warning said it didn't do checksums; really does.

Bad format string in version check.

- One file with all the module classes (spack/modules.py)
  - Has an EnvModule superclass that does most of the work and consolidates common code
  - Subclasses have specializations for different module systems (TclModule, Dotkit)

- One command (spack module) for all the types of modules to use
  - the one command is used by the scripts, only need to maintain in one place
  - has some subcommands for different module types, but they're handled mostly generically.

- Consolidate zsh support into a single setup-env.sh script.