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)
Actually, it only happens here, since this is the only place where we only have the short module name and something else (the location of the module file in this case), and we have to derive something else from that (the subdir in which the module lives).

In other cases, we can query the module naming scheme, which can give any of short/full module name, subdir for module file, module path extensions, ... directly.

I can see why it would make the code clearer though, let me see what I can come up with...