Clarify role of when-clause conditions in event iteration

[henrikt-ma]

Fixes #3813.

While I do think that this should be sufficient to consider #3813 fixed, it leaves me a bit uneasy that my intuition about the event iteration is not captured in any non-normative section. That is, the intuition is that event iteration must be continued when some computed solution to the model equations becomes invalid due to some of the updates taking place after the evaluation of the model equations. The intuition is also that once none of the computed solutions become invalidated, it should in principle be a no-op to evaluate the model equations one more time, so tools should err on the side of iterating one extra time rather than one time too little.

The two things taking place after evaluation of the model equations are the pre(v) := v updates and the execution of reinit statements. Thus, a tool erring on the side of iterating one time too much could simply test whether there is any change to a pre(v) or a state updated by a reinit. By noting that execution of a reinit implies that there is a pre(v) which will be updated from false to true, the condition may be simplified to the current rule in the specification.

However, the intuition about invalidated solutions to the model equations is a more intuitive starting point for optimizing the iteration, and in my opinion also a more useful way to abstractly understand what it is that the event iteration achieves:

• Event iteration ensures that the model equations are solved consistently before transient analysis may proceed forward in time after an event.

In view of the text proposed in this PR, it is particularly worth noting that the intuition does not suggest that a triggered when-clause should necessarily trigger continued iteration; the usual sorting of equations is sufficient, except for reinit which may change a state after it has been used. Hence, the conceptual idea of introducing implicit variables for the when-clause conditions is neither helpful for tools that want to avoid unnecessary iterator nor for users who are trying to understand optimized tool behavior.