feat: implementation of gestalt-DI

[pollend]

here is some experimental work with: https://github.com/MovingBlocks/gestalt/pull/87\

This is an implementation of gestalt DI. At the moment there is a ApplicationContext --> GameContext. Application context will contains all top level dependencies such as the audio system and the game context is the actual gameplay systems. This could be managed and split into different layers depending on different states of the application. each module has its own context so

This is how the current import scheme works with Gestalt modules so each module is only dependent on a child module and so forth. there is no way that moduel2 has a cyclic dependency on Module1

Application --> GameContext --> Module1 --> Module2 --> ... --> ModuleN  

This is a straightforward replacement of the context system that was pulled in from Terasology. Each context defines the services that are needed and at request the object is built up from the dependencies within that context and the parent context if it fails to get resolved in the current context. anything that used to be dependent on pulling from the context will declare the dependencies that are needed to build that object and the context will resolve building that object.

Unit tests are a matter of providing a serviceRegistry with the needed dependencies and the injection system will resolve those as need be. it should be easy enough to construct a mock object within the context and the system should handle the rest. reduces the burden of working backwards from the source to construct a test environment.

This handles a lot of the clear problems with the old scheme.

• dependencies are added in at some arbitrary point so its hard to determine what is and isn't available
• constructing a test environment is very reliant on understanding the couplings within the system so its necessary to work out dependencies to construct a working environment.

A lot of the code that is used to construct the game is gone and and has been handed over the DI system.

This also does away with reflections. this is also managed by gestalt-DI. I think @DarkWeird would have more information about that portion of the implementation. basically lets us do some scanning for a given type without paying the cost of walking the class path. accomplishes a similar goal to reflections bug handled through the annotation processor.

need changes from this PR: https://github.com/MovingBlocks/TeraNUI/pull/65

this PR replaces this PR: https://github.com/MovingBlocks/DestinationSol/pull/586

[pollend]

I guess we need these changes for the build to work: https://github.com/MovingBlocks/DestSolAndroid

[DarkWeird]

Needs https://github.com/MovingBlocks/TeraNUI/pull/70/ to work.

• restore playable state for desktop
• Create BeanClassFactory for injecting to Asset related classes
• Provide @Inject for every Asset related class
• using scanner for scan assets and ui packages (im too lazy to explicitly write all them in service)