Improve options for running jobs in parallel

[nicolas-kuechler]

Currently, experiments run in parallel but jobs within an experiment run sequentially.

This can lead to a lot of code duplication in suite designs to leverage parallelization.
An experiment is copied and something that is a $FACTOR$ is treated as a constant in two separate experiments.

(note, for single instance experiments running on Euler, this limitation is less of a problem because jobs can be executed in parallel on Euler)

We could investigate whether it is possible to define on an experiment level: n_env or something similar that defines how many times the environment defined in host_types is duplicated.

Options:

• do a preprocessing step on the design to split the runs into separate experiments and then do not change anything in the execution (would have to ensure that the run_id is preserved, otherwise the results will overlap
• have some functionality in the execution that checks that we only schedule runs with run_id % n_env == x or something. I think such a choice may be better suited because splitting experiments and preserving run_id could be complex.