Template IEEEST on its derived notch order

[lukelowry]

Description

Templates Ieeest on its notch order, derived from the notch coefficients, so each order has only its own states and a branch-free residual.

Depends on #566. Supersedes #460.

Proposed changes

• Add Ieeest<ScalarT, IdxT, order> and IeeestFactory, which derives the order from A1–A4.
• Realize the notch as its two denominator factors in series and evaluate block outputs inline, reducing unknowns from 12 to n + 4.
• Read parameters with ParameterReader and check them with ConfigurationChecks.
• Let VariableMonitor accept models with extra template parameters.
• Rewrite the tests and README.

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• N/A The CHANGELOG.md has been updated to reflect the changes.

Further comments

Zero lag time constants are now raised to 1 ms instead of bypassed, so that time constants are treated identically for all models. All validation cases containing IEEEST still pass. We could apply this model's approach in the future to the others to resolve any issues time constant might be contributing to #463

@superwhiskers @nkoukpaizan @pelesh I have consolidated all past reviewer comments when considering this final implementation for IEEEST, so your feedback was much appreciated in the superseded PRs.

[superwhiskers]

i've run the test locally, it passes. this is a significant improvement over the previous implementation ergonomically, so i think it's ready to merge once these comments are addressed

[lukelowry]

@superwhiskers Thank you for the suggestions I think this model is very clean, now. one of the cleaner implementations, too

Notice that the target branch is #566, not develop! That is intended to merge first since I used it here

[pelesh]

A few nits but I think this is good to merge.

[pelesh]

I really don't like such floating point comparisons. Can't we use model "order parameter" to set these values to zero?

[lukelowry]

No, I strongly feel that we should not have an order parameter exposed that way. It would require intimate knowledge of the implementation to change the parameters. This is a common enough model that it would cause real usability friction IMO.

is there a way we can do this safely? There must be a way to actually compare against zero, if that's truly the intended comparison.

[pelesh]

I will temporarily block merging this as it requires more offline discussion.