Load dependencies of SYSTEM toolchain by full name

[Flamefire]

This allows loading e.g. GCCcore/12.3.0/ncurses/6.1 without loading the GCCcore/12.3.0 toolchain module.
So we can use that as a dependency.

Note that this already works in the EasyBuildMNS because there the short and full module name are the same

Only in the HierarchicalMNS it fails because there 'Compiler/GCCcore/12.3.0/ncurses/6.4' needs to be used to load it.

A use of this is https://github.com/easybuilders/easybuild-easyconfigs/blob/8bca6595b2b975eb32eda0035613cf6fa17610a3/easybuild/easyconfigs/r/ripunzip/ripunzip-0.4.0.eb (from easybuilders/easybuild-easyconfigs#17959) which uses Rust as a build dependency

cc @Micket

Requires:

• Remove duplication in toy-build tests #5050

Because I didn't want to C&P the same code again. Last 2 commits are the relevant ones here

[boegel]

@Flamefire conflict to resolve?

[Flamefire]

It makes sense to merge #5050 first so I can rebase this such that some commits disappear.

That one should be trivial as it is a test-only change.

In any case: Do you agree with this approach at all? In Slack @ocaisa mentioned:

It's asking for trouble to allow dependencies higher up the hierarchy, that should only be possible if they are build dependencies
You would need very good sanity checks to ensure a runtime dependency does not slip in because of our use of rpath
With Rust maybe it is safe, but that's the exception rather than the rule

However it currently works for EB-MNS but not HMNS

I think I can limit this change to build dependencies but that doesn't solve the MNS discrepancy.
We'd need a check somewhere that runtime deps are same or higher in the module hierarchy and possibly a warning for build deps.

That is if we want to allow this at all. If not this PR is not required and we need to error out earlier.