Event-handling during preequilibration, presimulation and post-equilibration

[dweindl]

For more consistency (#2386) and for PEtab v2 support (#2662), we want event-handling during preequilibration, presimulation and post-equilibration.

Rough plan:

• Refactor ForwardProblem: extract some EventHandlingSimulator (class or function) that can be used in all four periods (if simulation-based) that does the event and (optionally) measurement processing. Also extract a SimulationWorkspace for the data structures currently stored in ForwardProblem that can then be passed to the different EventHandlingSimulators. (Started in Handle events during presimulation #2777 for presimulation)
• Do the same for BackwardProblem (Started in Refactor BackwardProblem for presimulation #2780)
• Enable presimulation with ASA (Presimulation with adjoint sensitivities #2786)
• Event-handling during pre-equilibration
  • FSA, FSA (Handle events during equilibration #2859)
  • FSA, ASA (Event handling during pre-equilibration with FSA before ASA simulation #2881)
  • ASA, ASA (Event-handling during pre-equilibration ASA / ASA #2889)
• Event-handling during post-equilibration
  • FSA (Event-handling during post-equilibration for FSA #2920)
  • ASA (Handle events during backward simulation of post-equilibration #2925)

[dweindl]

How do we want to deal with the case of steady-state simulations and events with known trigger times?
At least for events with a single trigger time, I'd say we should at least simulate until that event triggered.
For other events it's more difficult, since they might in principle trigger infinitely many times (say, tan(t)). However, they aren't handled yet as fixed-time events, so we can probably ignore that for now.

Related to #2673.

[FFroehlich]

How do we want to deal with the case of steady-state simulations and events with known trigger times? At least for events with a single trigger time, I'd say we should at least simulate until that event triggered. For other events it's more difficult, since they might in principle trigger infinitely many times (say, tan(t)). However, they aren't handled yet as fixed-time events, so we can probably ignore that for now.

Related to #2673.

If steadystate is reached before events are triggered, I‘d say stop there. Otherwise you end up with simulation routines that depend on how well your symbolic engine works, which I‘d prefer to avoid. But sounds we may want to say a word about this in the PEtab spec.