Bugfix/multiple simulation runs

[stiesssh]

Current behavior: Slingshot cannot execute multiple, successive simulation runs, among others because the models do not get updated.

New behavior: Slingshot can execute arbitrary many successive simulation runs on various models :)

Major Changes:

1. created distinct extension point for system and simulation extension. distinguished between system and simulation extensions.
   bind system extension in the parent injector for the entire simulator instance. bind simulation extension in the child injector for one simulaiton run only.
2. do not skip the init operation of SlingshotSimulationDriver. if we do not re-init the driver, the extensions are not recreated and the models already injected in the extensions are not updated and we cannot rerun on different models. yes, this requires us to create a new child injector for each simulation run, but i could not find any confimation on whether this is acutally a memory leak, thus i decided to do it anway :)
3. commit atrocities to the SimulationEngineSSJ. if we reload the extension, we must also re-register at the engine. but before we must kinda reset the engine.. it's ugly. but for now i could not think of anything else :/
4. remove that workflow configuration and instead provide SimComConfig via the drive submodule.

Minor Changes:

• Some renames and improvements to error messages.

Misc

related to https://github.com/PalladioSimulator/Palladio-Analyzer-Slingshot-Extension-Monitoring/pull/4 and https://github.com/PalladioSimulator/Palladio-Analyzer-Slingshot-Extension-PCM-Core/pull/11

if this is merged/rejected, the other two PR should probably be handled in accordance.

[stiesssh]

[..] I do think it is better to have two extension points as suggested in this PR, because it improves code readability and clearly distinguishes these responsibilities, and (I think) even performance.

After hearing your arguments about the initial design, i get the intention. As mentioned above, we should probably discuss the pros and cons in person.

[..] I would suggest to also split the AbstractSlingshotExtension class into these two responsibilites [..], so that extension developers are not able to mix them up.

I agree.

I'll put this PR on hold though, untill we come to an unanimous decision on where (extension points / containers) we want to distinguish the system from the slingshot extensions.

[stiesssh]

replaced by PR #8.