integrationtest to verify limits of iceoryx

## Brief feature description

In `iceoryx_posh_types.hpp` defines maximum supported amounts of resources like ports, history size, mempools, shared memory segments etc. free to use by the user.

We require tests to check if those limits are compatible with each other and maybe connect them with if necessary. Additionally, we require integrationtests which verify that iceoryx runs stable even when all resources are in use.

## Detailed information

In a first step it would make sense to split up `iceoryx_posh_types.hpp` into a `iceoryx_config.hpp` file and into a compile time `iceoryx_config_verificator.hpp`. In the config file only the global `constexpr` are defined and we put all the `static_asserts` into the verification file. All the remaining class and function definitions have to be moved to more fitting places. Maybe a `iceoryx_common.hpp` file would make sense.
Finally, when having tightly coupled `MAX_` values then only one of those values should be present in `iceoryx_config.hpp`. The coupling of the other value should happen in `iceoryx_config_internal.hpp` so that the user cannot create incompatible configurations.

### List of coupling problems (not complete):
* Can we move certain `MAX_` values to `platform_settings.hpp` since most system resources have platform specific limits
* Maximum amount of publishers and maximum amount of supported entries in service registry must be equal
* When pursuing approaches for pub/sub find service: max number of apps and max number of subscribers per publisher must be equal
* Do we really require a maximum history size of 2048 when there is no mempool with 2048 chunks of a specific size? A user would get an out of chunks error before the history is completely filled
* Does it make sense to couple maximum chunks hold in parallel to the history size?
* Do we require global `MAX_*` specifications for message queues in there. This is an implementation detail which is platform dependent. Could this be integrated into the posix wrapper?

### Internally used resources

A user does not know what kind of resources we are using internally. So it may happen that they are surprised that they configured 6 publishers but they can only create 1 (since the remaining 5 are used by the introspection). This can be solved by having a `MAX_PUBLISHERS` variable in the public `iceoryx_config.hpp` and a `MAX_PUBLISHER_IN_SYSTEM=MAX_PUBLISHER + PUBLISHERS_USED_BY_INTROSPECTION` in the `iceoryx_config_internal.hpp`.

But still it may happen that a user then breaks its own contract and uses more publishers than configured and maybe internal services are then crashing. In a further step it may makes sense to decouple internal resources completely so that they are always available for roudi.

## To Do

- [ ] Split up `iceoryx_posh_types.hpp` into `iceoryx_config.hpp`, `iceoryx_config_verification.hpp`, `iceoryx_config_internal.hpp` and `iceoryx_common.hpp`
- [ ] Couple internally used resources with public configuration. See `MAX_PUBLISHER_IN_SYSTEM=MAX_PUBLISHER + PUBLISHERS_USED_BY_INTROSPECTION`
- [ ] Write small integration tests first where only a single limits are verified. If we encounter here that certain values are coupled combine those values in either one value (if they are equal) or define the one with the other outside of the config where it is needed. When having coupled config entries only one should be available for the user the other one should be configured internally with the coupling it requires.
- [ ] Write single integration tests which tests the maximum of everything.
- [ ] `MAX_NUMBER_OF_NOTIFIERS_PER_CONDITION_VARIABLE`, `MAX_NUMBER_OF_EVENTS_PER_LISTENER`, `MAX_NUMBER_OF_ATTACHMENTS_PER_WAITS` should be reasonable coupled to the maximum allowed ports (subscriber/publisher/service/client). Since some users may would like to handle the whole communication over a waitset/listener. See: #1109
- [ ] `MAX_NUMBER_OF_NOTIFIERS_PER_CONDITION_VARIABLE`, `MAX_NUMBER_OF_EVENTS_PER_LISTENER`, `MAX_NUMBER_OF_ATTACHMENTS_PER_WAITS` should be configurable via CMake

Start by reading iceoryx_posh_types.hpp and the configuration-related items in the issue, then review issue #1109 for the waitset and listener limits. The work is done when the configuration split, internal coupling, CMake configurability, and single-limit and all-resources integration tests described in the checklist are implemented and pass.

Written by the indexing model from the issue text.