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)
no, it's a bug in EB, see also #996 

In a hierarchical scheme (i.e. where `$MODULEPATH` extensions come into play), you should not include load statements for dependencies that make you travel down in the hierarchy.

See the example included: there should be no load statements for the GCC and OpenMPI deps, since you need to load those modules first before you can access the module being installed.

Not doing so breaks `swap`, for example.