Modularization: Structure of Base Modules

Today we have a structure of modules that look similar to the following illustration:


While this is already a step in the right direction we need to invest more work in the modularization of the base modules to create a more flexible, maintainable and understandable system.

## Removing the common module
Today the common module contains a lot of functionality for topics like cryptography, concurrency, io, metrics... We need to split this module in several submodules where each module has a single topic / feature set. By doing so it is much more easy to define dependencies between functionalities and have dependencies for specific topics as shown in the following diagram:


The diagram already shows several benefits of this approach. The topic specific modules can have external dependencies but some of them might only need Swirlds-base as a dependency. This makes the maintenance of such module much easier and a developer can not use any external class by mistake.
It is ok to let one of the modules depend on any other module. But by doing so you can really specify what topics / features depend on each other. By using the Java module system we can define such dependencies in a really powerful way.
In general each of the modules can depend on Swirlds-base without any issues. Next to this our `NonNull`/`Nullable` annotations should be available at compiletime (and never at runtime).

## Split between public and private API

For the Config API we created 2 modules: 1 module that contains the public API of the configuration functionalities and 1 module that contains the implementation of the API. The implementation should never be on the class path on compiletime and only used at runtime. By introducing the Java module system we can achieve the same behavior without doing that module split. The private API can be defined as private by the Java module system and be placed in the same module as the public API. When we created the Config API the `swirlds-base` module was not present and `swirlds-common` contained several functionalities that were needed to create the implementation of the API. Since we wanted the public API to have no dependencies we needed to split the module and let the implementation depend on `swirlds-common`. Once we have refactored & removed `swirlds-common` I assume that we can simply define 1 module for each topic and do a hard definition and split of public and private API in each module.