Revisit architecture and cleanup

[mbrandenburger]

A few observations regarding the current code base:

• The central piece of the token SDK is the service registry. We use providers to create and manage service instances.
  The service registry allows to register providers for specific services (e.g., configuration, network, vault, tms, events,...).
  I believe the name service registry is misleading, as it does not register service instances, but rather their corresponding provider implementations.

• Some providers maintain references to other providers (nested providers). For instance, the TMS provider requires a vault provider. When a TMS instance is created, it internally keeps a reference to the VaultProvider rather than a reference to a vault instance. It seems that this is not necessary and may be just the result of a quickly growing code base. :) Same issue with the use of the selector provider and certification client provider.

• The audit provider is actually named audit manager. Looks like a naming inconsistency.

I suggest that we revisit the existing services and introduce a consistent naming convention for these services and their providers. Ideally, services can define or re-use dependency interfaces and service instances can be constructed using a proper constructor function or via direct instantiation with public dependencies. Thereby we enable easy unit testing. Service providers are responsible to construct service instances and fetching the corresponding dependencies.

[adecaro]

@mbrandenburger is this still relevant? If yes, could you push a PR to address it?