Cleanup Reactions language

[HeikoKlare]

This PR cleans up the Reactions language, removes unused classes and functionality, simplifies the runtime classes and the generated code. It particularly affects the runtime project but also improves the language itself.

Major changes are:

General:

• Cleanup of unused methods in runtime classes and code generators

Runtime:

• Unification of naming for Reactions runtime classes: We had IReactionRealization, AbstractReactionsRoutineRealization etc. before.
• Addition of interfaces for all Reactions runtime classes and exchange of dependencies of other classes to those interfaces.
• Removal of CorrespondenceFailHandler: We had different handlers for failing correspondence retrievals, but they were not integrated properly (they were not exchangeable), such that always an exception was thrown anyway. Since we currently have no need for that functionalty, it is removed rather than integrated.
• Removal of RoutinesFacadeExecutionState by separation of passing the execution context of a Reaction throughout the execution process (i.e., we only have ReactionsExecutionState now) and tracing the call stack of Reactions and routines.
• Simplification of instantiating routines facades and passing a ReactionsExecutionState throughout the execution.
• Removal of ReactionsExecutor: We had redundancy between the ReactionsExecutor and a ChangePropagationSpecification for each Reactions segment. Now only the ChangePropagationSpecification remains

Language:

• Removal of operation registry from Reactions code generator: Methods are now explicitly created rather than implicitly putting them implicitly into a map upon creation and adding them to a class later on
• Improval of naming for routines facade classes: They are now named according to the Reactions segment they belong to rather than having a generic name.

[tsaglam]

As far as I can judge it looks good!

[JanWittler]

Why can't we make a generic class to have this explicit?

[HeikoKlare]

This was a quite complicated thing. I will have another look it at, because I am not sure anymore whether this is conceptually necessary or just to not bloat up the code generation as we then have to add the generic type parameter basically everywhere.

[HeikoKlare]

Proposal: We document that point in an issue. Then I will either address that issue in a subsequent PR or document in that issue why we cannot/should not change that, as soon as I have checked it. If this can be improved, it would further bloat up this PR and reviewing the further changes will become even harder than it was for the current changes. Do you agree, @JanWittler?

[JanWittler]

Fine with that

[HeikoKlare]

Done in #46.