Split RunTarget/Component config from LaunchManager config?

### What

# Problem

Currently, the Launch Manager is configured with a single json file that mixes the RunTarget/Component configuration with Launch Manager daemon configuration (initial run target, alive monitoring thread periodicity, watchdog, ..).
Once we want to support multiple configuration files, this may become a problem.
While there may be an arbitrary number of RunTargets/Components defined in different files, the Launch Manager daemon settings must exist at most once.

This may create conflicting situations at runtime:
Example:
Config File 1:
- initial run target: "Target1"

Config File 2:
- initial Run Target: "Target2"

What initial run target shall launch manager use? First config file loaded wins?

Currently, only few launch manager daemon settings are configurable, but in the future we need to add more settings:
- Alive monitoring thread periodicity
- initial run target
- fallback run target
- scheduling policy of launch manager
- scheduling priority of launch manager
- number of worker threads
- security policy for launch manager
- core affinity for launch manager threads
- Launch Manager main loop cycle time
- ...

# Solution Ideas

## Option 1: Move launch manager daemon configuration to a separate configuration file

* Introduce a second configuration file containing all launch manger daemon configuration
* The file must exist at most once in the filesystem and is loaded at startup
* The file is optional, defaults are used when values are not configured or file is not available

Pro:
* Clear separation

Con:
* Complexity of another configuration file

## Option 2: Move launch manager daemon configuration to CLI options

* Make the launch manager daemon configuration into CLI options
* Use defaults if option is not provided

Example:
`launch_manager -w -i -f ...`

- `-w ` : default 8
- `-i ` : default "Startup"
- `-f ` : default "fallback"
- ...

Pro:
* Clear separation
* Less complex than having another configuration file

Con:
* Not ideal for specifying many parameters
* Not great for nested values

## Option 3: Keep launch manager daemon configuration in the existing json schema, but separate it in a dedicated object

* Keep everything together in a single json schema
* Separate the launch manager daemon specific settings in a dedicated object (called "daemon" below)
* The "daemon" section must only exist in a single json file can only be available in the set of initial config files
* If "daemon" section is encountered in any further config file, the config file is rejected (no merging of settings)

Example:
```json
{
"components": [...],
"run_targets": [...],
"daemon" : {
"initial_run_target": "abc",
"scheduling_policy": "SCHED_RR",
....
}
}
```

Pro:
* Smallest change to the current configuration structure

Con:
* Less separation than the other options
* A configuration file content need to consider if its loaded at startup or later at runtime
* Only a file loaded directly on startup can contain the launch manager parameters

### Acceptance Criteria (DoD)

* Decision taken

### How

_No response_