Constrain use of 'delay' with zero delay time

[henrikt-ma]

This is a new take on #3245, picking up where it was left with the comment #3245 (comment). (I am revisiting this now because of my ongoing test implementation of delay with event generation.)

I think this solves the issue with an acceptable tradeoff between backwards compatibility and feasibility of actually implementing according to specification:

• As @MarkusOlssonModelon seems to have suggested in phone meeting, delayTime = 0 is forbidden for time-varying delayTime.
• In the two argument form delay(u, delayTime), the "new" evaluable variability is used to constrain delayTime, making it possible for tools to determine at translation time whether delayTime has been set to zero, but not forcing tools to evaluate.
• By allowing delayTime = 0 in the two argument form, we avoid the need to give complicated rules for when it is an error to have delayTime = 0 in guarded expressions such as if tau > 0 then delay(u, tau) else u.
• In principle, the funky technique of only evaluating delayTime when the value would be zero can be avoided by generating different equation systems for the two cases, and make an initialization time decision of which case to use. (Not expecting any tool to actually do it this way.)

[HansOlsson]

Hans:

• Should add QoI for run-time check.
• Would prefer that if parameter delayTime is non-evaluable it is still valid, but does not support delayTime=0.

[henrikt-ma]

Hans:

• Should add QoI for run-time check.
• Would prefer that if parameter delayTime is non-evaluable it is still valid, but does not support delayTime=0.

I have updated the text accordingly.

I think it would be good, though, to have a migration path for avoiding semantics depending on whether an expression is evaluable. It could be achieved with two deprecations:

• Deprecate the two argument form with non-evaluable delayTime.
• Deprecate allowing delayTime = 0 with the three argument form.