enforce that hiddendependencies is a subset of dependencies

by request of @stdweird 

@ocaisa, @geimer: heads up on this one, since this makes things stricter compared to EasyBuild v1.15.x

We're enforcing here that all entries of `hiddendependencies` are also listed in the `dependencies` list.
Before EasyBuild resolving dependencies, it will filter out the dependencies that are listed as hidden from the `dependencies` list, so semantics w.r.t. installing missing modules hidden is retained.

We want to avoid that contributed easyconfig files contain site-specific decision w.r.t. whether modules should be installed hidden or not.

By ensuring that `hiddendependencies` is a subset of `dependencies`, it becomes trivial to make easyconfig files using `hiddendependencies` site-agnostic: simply remove the `hiddendependencies` specification.

The `hiddendependencies` easyconfig parameter still has its merit (to indicate to `--robot` which modules must be installed hidden), and will not disappear.

Sometime in the future, we will also add support for resolving entries in the `dependencies` list with an existing hidden module, as a fallback in case the module is not available non-hidden. When neither are available, the module will be installed non-hidden via the robot, unless it is included in the `hiddendependencies` list (in which case it *has* to be available as a hidden module).

@ocaisa, @geimer: thoughs on this?
For now the entries of `hiddendependencies` are passes through `_parse_dependency`, so they have to be name/version tuples (and can include suffix/toolchain optionally), like other dependencies in `dependencies` or `builddependencies`.