Feature request: Force a Correction step if Module-Level Inputs Involve Step Changes

[jjonkman]

Is your feature request related to a problem? Please describe.
If a module-level output used as input in other module (such blade-pitch angle or generator torque passed from ServoDyn to ElastoDyn) involves a step change, the extrapolation of inputs to ElastoDyn results in inaccuracies that require a correction step to resolve (requiring the user to set NumCrctn > 0).

Describe the solution you'd like
It would be great if the OpenFAST solver was "smart" enough to identify that a step change of input has occurred and force a local correction step rather than requiring that a correction step be added in each time step of the simulation as set by the user. The hard part will be defining a general threshold that indicates whether an input step change has occurred. Given that most module-level inputs are either motions or loads, I imagine that this threshold could be derived from a characteristic length in the wind turbine (such as the tower height or blade length in ElastoDyn) and characteristic mass (such as UJacSclFact). It would be great if this could be addressed in the ongoing implementation of tight coupling.

Additional context
An example of the issue is demonstrated in the following OpenFAST discussion: #2266.

[andrew-platt]

I assume we probably want to do this in v 5.0.0