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

Inizia esaminando la gestione di @Dependencies e l’esempio FlexibleMovementTestingEnvironment, quindi riproduci il comportamento a cui fa riferimento FlexibleMovement/pull/3. Determina se sono previste annotazioni dei figli, dipendenze transitive dagli asset e dipendenze esplicite dal modulo padre; il lavoro è completo quando la semantica scelta è coperta dal test FlexibleMovement pertinente.