Annotation-based dependency definition seems quirky

Two issues noted on Discord just recently in #architecture relating to something like @Dependencies({"FlexibleMovement", "CoreAssets"})

1. Apparently this is currently needed in child classes if you use a common utility class for some basic setup (see for instance FlexibleMovementTestingEnvironment in https://github.com/Terasology/FlexibleMovement) - the annotation doesn't get inherited by default
2. Transitive dependencies may be honored, but possibly not for assets. This is odd, but in a FlexibleMovement test with the above @Dependencies statement, despite the FM module itself having a dependency tree including CoreAssets the dirt and water block families were not found if CoreAssets wasn't explicitly included in the list

I also sort of wonder why we have to explicitly call out the parent module as a dependency? 🤔 And for that sake - if the parent module's dependencies were to be respected and just loaded normally out of module.txt why would @Dependencies even exist? Is there a case where you'd have a test in a module depend on a different module the test-owning module itself doesn't depend on? Or is it more that we'd want the ability to only activate a subset of the dependency tree? That seems like it would lead to tests differing more than needed from the mainline code.

https://github.com/Terasology/FlexibleMovement/pull/3 was used for some of the testing

Beginne mit der Überprüfung der Behandlung von @Dependencies und des Beispiels FlexibleMovementTestingEnvironment und reproduziere anschließend das von FlexibleMovement/pull/3 referenzierte Verhalten. Lege fest, ob untergeordnete Annotationen, transitive Asset-Abhängigkeiten und explizite Abhängigkeiten vom übergeordneten Modul vorgesehen sind; abgeschlossen bedeutet, dass die gewählte Semantik durch den relevanten FlexibleMovement-Test abgedeckt ist.