[WIP] Enable operator split reactions at end of the timestep as well

[anne-glerum]

For discussion with @gassmoeller

This PR enables the user to choose to apply the operator split at the end of a timestep instead of at the beginning. The PR also requires this order when elasticity is included.

Since the time interpolation of the current linearization point is no longer called after the reaction solve, the compute_reactions function requires no changes I think.

I ran the simple stress relaxation benchmark, and this shows the same results. In this benchmark, the stresses only decay with a factor \eta_ve / \eta_e every timestep applied through the reactions. As the timestep is fixed, it doesn't matter whether the reaction solve is applied at the beginning on the previous stress, or at the end of the timestep on the still unchanged stress.

Question 1: When we discussed making this change, we decided to put the compute_reactions after the new timestep is computed and to pass this timestep to the reaction solve. Looking at the code now, I wonder why this would be necessary. Wouldn't we want to use the same timestep that is used for the advection and rotation of the stresses?

Question 2: In main, atm no reaction solves occur during timestep number 0. But in timestep number 1, a reaction solve does occur. Since this reaction actually belongs to t0, should it even happen?

TODO:

• Check whole of elasticity.cc to update the comments
• Check that the reaction rates are computed at the right timesteps
• Also reorder the update for the particles, so far only for fields. For particles, the update happens every time after they are restored to their state of the beginning of the time step. But as the calculation of the reaction rates doesn't have to be changed, they are still correct. The signal the particle update connects to could be changed, so that the update is also applied at the end of the time step.
• Run more benchmarks

For all pull requests:

• I have followed the instructions for indenting my code.

For new features/models or changes of existing features:

• I have tested my new feature locally to ensure it is correct.
• I have created a testcase for the new feature/benchmark in the tests/ directory.
• I have added a changelog entry in the doc/modules/changes directory that will inform other users of my change.