update / rethink AbstractSystem API and definitions

[isaacsas]

Current version:

https://docs.sciml.ai/ModelingToolkit/stable/basics/AbstractSystem/

I think it might be helpful to MTK contributors, and downstream libraries building on MTK, to have an official, updated, minimal API for what functions AbstractSystems should support/dispatch, what fields they must have, and if there are type requirements on these fields (hopefully in a non-breaking manner from what was implicitly assumed in the past). https://docs.sciml.ai/ModelingToolkit/stable/basics/AbstractSystem/ is old, and not very comprehensive in what it lists, and really ignores a lot of internal assumptions about which functions should work for all system types.

Without such an official listing, there can sometimes be an implicit assumption that one can write code for AbstractSystems that really only makes sense for ODESystems (and/or a few other system types) via making implicit assumptions about the types of equations(sys) or via calling functions that are really only defined for ODE type systems. We've had several cases recently, for example, where equations(sys) was implicitly assumed to return Equations, which has never been true for either JumpSystems or ReactionSystems (but which both, I think, are consistent with the stated API as it makes no requirements on the types of equations).

[isaacsas]

Here, for example, are some dispatches we've had to define in Catalyst. I don't know that all of these are actually needed to avoid issues with an AbstractSystem, but a non-trivial subset likely are:

# for systems
equations(...)
unknowns(...)
flatten
extend
validate
== 

# for non-Equation equation types to work with MTK functions
# the non-Equation type needs dispatches on:
Base.show 
hash
==
namespace_equation
is_diff_equation
is_alg_equation
get_variables!
modified_unknowns!
validate

[ChrisRackauckas]

I think we're getting close. I think we need to nail down the representation for boundary value problems and optimal control, and then we finally have our full set of "standard" system types. I would want to base the interface off of seeing what we actually need.