IEEEST Stabilizer Improvements/Corrections

[lukelowry]

Description

Fixes and cleans up the IEEEST stabilizer implementation and documentation.

This updates the older initial implementation style so that reduced-order notch filters and zero denominator time constants are handled consistently

Proposed changes

• Replace the branchy/safe-inverse notch logic with a fixed DAE form using differential tags.
• Initialize IEEEST from the attached input signal instead of forcing all states to zero.
• Document the implemented equations, initialization, derived parameters, and unsupported compatibility parameters.
• Tests for initialization, residuals, invalid wiring, invalid notch parameters, zero time constants, and Jacobian consistency.

Checklist

• All tests pass for the focused PhasorDynamics coverage.
• 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.

Changelog changes N/A

Further comments

This is cleanup/correction work for the existing IEEEST model, not a new model

[lukelowry]

@pelesh this fix is also ready to be merged I forgot to make a PR for this one.

[pelesh]

The logic governing changing differential into algebraic equations and vice versa does not seem to be sustainable. This requires more offline discussion.

[pelesh]

I am not sure if this is a good idea. We are changing equations based on whether we defined other equations to be differential or algebraic. Furthermore, we rely here on implicit bool-to-integer and integer-to-floating point conversions. This logic needs to be implemented in a different way.

[lukelowry]

I am not sure how to implement this without introducing template-y solutions. Do we want to move toward something like this where we define the model conditionally?

template <class ScalarT, typename IdxT, Order order, Block t2, Block t4, Block t6>

But there are 31 different permutations, so there would be a lot of duplicate code. I don't know what the general approach should be, so I am open to any suggestions.

[pelesh]

The logic implemented this way will break when we add solvers that require DAEs implemented in Hessenberg form.

[lukelowry]

Opened an issue #463 where hopefully we can discuss the general approach to take since this impacts almost every model

[lukelowry]

I have rebased and adjusted the formulation to align with #463 .