:recycle: [Service Configuration] Service Configurations refactoring

[dseurotech]

This PR continues the work initiated during the DI introduction, separating the logic of service configuration management into the ServiceConfigurationManager implementations. This also changes how ServiceConfigurationManagers are wired - managers are no longer annotated with @Named but are wired as contributors to a Map, e.g.:

    @ProvidesIntoMap
    @ClassMapKey(UserService.class)
    @Singleton
    ServiceConfigurationManager userServiceConfigurationManager(

Unfortunately Guice does not support overriding for Map binder entries, therefore each service configuration manager has been isolated in a separate Module wiring file. If you need to change the behaviour of any ServiceConfigurationManager, configure the locator.xml to ignore that full class name (including the package name) and provide a new implementation.

Having all service configuration managers in a map was functional to solve a vulnerability issue present in the Rest Apis, which were instantiating classes based on the name provided by the user. Now the value provided by the user is matched (at the string level) with the list of available keys.

Furthermore, within this PR the logic to retrieve the TMetadata for services has been isolated in its own provider, allowing for alternative implementations.