Multiple environments (RouDis)

Hi what's the recommended path of running two separate iceoryx environments on the same box if possible ?

I rather not send under separate topics and share RouDi. I see that Roudi can start with an unique Id but the PoshRuntime can't register per runtime Id... -I suspect I'm missing something.

Please advice.
Thanks!

Edited from elBoberido on Feb 13th 2024

## Tasks

- [x] using unique RouDi ID as prefix in the resource names -> #2185
- [x] non-static posh runtime/node
- [x] builder pattern for the posh runtime/node to easily create multiple runtimes for various RouDi
- [x] gracefully handle the non-existence of a RouDi; operation can continue in a degraded fashion only with the available RouDi
- [x] builder pattern for the endpoints to determine which runtime to use and handle errors more gracefully
- the runtime itself could act as factory for the endpoint builders
- [x] standardized environment variable to define the domain ID for the applications -> `IOX_DOMAIN_ID`
- [ ] the domain ID must be added to the `segment_id_t` in order to have multiple active runtimes in the same process
- each runtime needs to register to a different RouDi
- if there are two runtimes trying to register at the same RouDi, the pointer repository registration will fail
- this could be solved via ref-counting on the register/unregister calls
- [ ] port all code to the new builder pattern API
- [x] node
- [x] publisher
- [x] subscriber
- [x] waitset
- [x] client (via #2425)
- [x] server (via #2425)
- [x] listener (via #2425)
- [ ] service discovery
- [ ] extend the C bindings for the new API
- [ ] deprecate the old API

Since this is a larger feature and most probably won't be finished at once, the changes will either live on a separate feature branch or if possible behind a feature flag, e.g. `IOX_EXPERIMENTAL_POSH`

Start by reviewing the open tasks around segment_id_t, multiple active PoshRuntime instances, service discovery, and the C bindings, alongside the completed builder-pattern work and IOX_DOMAIN_ID. Done means the remaining unchecked tasks are implemented, multiple runtimes can register with separate RouDi instances in one process, and the old API is deprecated as planned.

Written by the indexing model from the issue text.