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

Start by reviewing the @Dependencies handling and the FlexibleMovementTestingEnvironment example, then reproduce the behavior referenced by FlexibleMovement/pull/3. Define whether child annotations, transitive asset dependencies, and explicit parent-module dependencies are intended; done means the chosen semantics are covered by the relevant FlexibleMovement test.