filter out load statements that extend the $MODULEPATH to make the module being installed available

This is a fix for #996.

I tried very hard to make this a generic fix, i.e. one that should work with any hierarchical module naming scheme, not just the 2-level one using `Core`, `Compiler/<comp_name>/<comp_version>` and `MPI/<comp_name>/<comp_version>/<mpi_name>/<mpi_version>`.

Basically, what is being done now in `make_module_dep` is to figure out which dependency module is responsible for extending `$MODULEPATH` with the location where the module being installed will end up. That module is being excluded from the list of dependencies for which load statements are included in the generated module file.
This is done recursively: the module that makes the excluded dependency module being available is then also excluded, etc. Until the top of the hierarchy is reached, or none of the dependencies extends `$MODULEPATH` with the specified path.

This results in `GCC/4.8.2` and `OpenMPI/1.6.4` being excluded in a module built with a `gompi` or `goolf` toolchain, and should also work in other hierarchical module naming schemes.

@rtmclay: Does this make sense to you?

(CC: @ocaisa, @olavks, @pforai, @kcgthb, @geimer)
I don't see the use of determining the number of components?

That would require something like:

```python
depth = len(dep.split(os.path.sep))
full_mod_subdir = drop_last_n_path_components(modfile_path, depth)
```

Seems needlessly complicated