Modules in directories and fixes for setup-env.csh

[glennpj]

This PR puts module files for the same program in the same directory named for the program. This will require the modules to be regenerated,

spack module refresh

So, binutils, for example, would be laid out as follows:

ls $SPACK_ROOT/share/spack/modules/linux-x86_64/binutils 
2.25-gcc-4.8.5-kby6upoybmx3sz32dpzsalwol3dbx44r  2.25-gcc-5.3.0-6blubrftgydrex3mtrysorgewrg67pbf

This is a common scheme for module files and opens up several features.

1. With different builds of the same program in the same directory a conflict can be set up based on directory name.
2. It is possible to set a default version of the package in the directory.
3. In the absence of an explicit default version, the module tool will determine one based on name.
   This is where there is an issue with spack generated modules as the dag_hash could wind up playing a role here.
4. If the default is acceptable the module can be loaded with the shortcut name, which is the directory name

I made DotKit have the same structure but I do not know much about DotKit so I do not know if that is appropriate. If not, that could be changed. This requires the spec.name to be available in the setup-env scripts. While I was testing this I took a stab at fixing the csh $SYS_TYPE handling. I tried to make it consistent with the '.sh' version but I may be missing something on that.

The main remaining issue is setting a default value. For the module heuristics the hash will lead to unpredictable settings if the modules can not be distinguished prior to the hash. For manual site specific settings, the hash is not human parsable so I think the naming scheme for module files may need to be tweaked down the road. Here is an example of what lmod sees for binutils on my system.

module avail binutils

-------------------------------- /home/gjohnson/spack/share/spack/modules/linux-x86_64 ---------------------------------
   binutils/2.25-gcc-4.8.5-kby6upoybmx3sz32dpzsalwol3dbx44r
   binutils/2.25-gcc-5.3.0-6blubrftgydrex3mtrysorgewrg67pbf (D)

  Where:
   D:  Default Module

Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".

[luigi-calori]

I' am interested and was willing to implement: useful if want to expose spack built modules along with others.
Have downloaded and evaluated on existing repo by doing spack module refresh
Seems to work well
Anyone see possible issues? Otherwise I would like it to be merged.

It would be good also being able to customize the module body, like using a kind of modulefile template (to be defined at site level) filled with current code

[glennpj]

The functionality introduced by this PR is done in a much better way in #744.