Dependency injection refactoring (Guice)

This refactoring addresses the following issues:

#### Standardized Dependency Injection
Vidada is heavily using Dependency Injection (DI) - which is a good thing, but we currently use a very basic, custom ServiceLocator approach to do it. This refactoring uses the standard javax.inject Annotations (`@Inject` & `@Singleton`) to define the DI. This avoids any dependency to a concrete DI Container Framework.
[Guice](https://github.com/google/guice) is used as the lightweight Dependency Injection Container. Primary motivation for this framework is its extendability and the fact that no XML config is required.

#### Unit-of-Work handling replaced by `@Transactional`
To properly work with Hibernate and JPA, a solid Session / Transaction handling is required. A session must span over the whole call stack of a service method, thus Aspect Oriented Programming (AOP) is required.
Vidada currently uses a very simple [custom Unit-Of-Work system](https://github.com/IsNull/archimedesJ/tree/master/archimedes.core/src/archimedes/core/aop) to achieve this. While it worked well, it is not a standardized approach. Further, since the Unit-of-Work System was not part of the Dependency Injection, it required to wrap every method in a `runAsUnit(() -> { ... })` Context manually.
This has been resolved by using Guice and the `@Transactional` attribute, which is very similar to the EJB transaction handling.

#### Drawbacks & left TODO
* The not so pretty thing is the fact that the `@Transactional` attribute is not standard Java and resides in the _com.google.inject.persist_ namespace.
* The system still uses the IVidadaServer Facade which holds all Service Interfaces (however, delegated to the DI System). 
* Some non critical, non persistence aware services are still in the old ServiceLocator.