support for hierarchical module naming schemes

@geimer: this should fix the problem that's blocking you right now

I might need to figure out one more thing w.r.t. the devel module name before this really works for you, I'm looking into that...
I really don't feel like shuffling things around again because one module is getting too big (I know you feel that stuff like this should be handled when we bump into it, but sometimes you want to be able to merge PRs at some point rather than redesigning things again).

I agree it's getting too big, but reorganising that as a part of this PR is a (huge) pain... In fact, it should be multiple additional PRs to keep things manageable for testing/reviewing.

I did a single pass over `easyblock.py` and factored out the low-hanging fruit, which helped a bit, but it could use another more extensive sweep.

Done:

* flesh out `use_group` into `systemtools` module
* get rid of unused `print_environ` and `verify_homepage` methods (legacy dead code)
* move `set_parallelism` method to `det_parallelism` function in `systemtools`
* move `det_installsize` method to `det_size` function in `filetools` module

Candidates for factoring out functionality to separate functions:

* `fetch_*` & `obtain_file` => to `filetools` module (can of worms)
* `make_*module` > to `module_generator` module
* `skip_extensions` and the bulk of `extensions_step` could live in the `extension` module; `skip_extensions` can be renamed to a function `filter_extensions` that takes a list of extensions and returns a filtered list
* the body of `sanity_check_step` could be implemented in `filetools` (for sanity check paths) and `run` (for sanity check commands); similar for `cleanup_step`, 
* better synergy between `build_easyconfigs` and `build_and_install_one` functions; they both do the same (and are both used), but in slightly different ways