Unify constraint-based methods, minimize trapping class, add helper functions

[Jacob-Stevens-Haas]

Currently, there are two ways of enforcing stability in discovered models: StabilizedLinearSR3 and TrappingSR3. The latter requires two manual steps: adding constraints from the make_constraints function in example 8, and strengthening the default regularization $`/\eta$ from 1e-20 to something larger.

A few other issues I see:

• Trapping largely follows the behavior of ConstrainedSR3, but inherits from SR3
• Lots of repeated CVXPY code copied across SR3, ConstrainedSR3, and TrappingSR3
• [BUG] Are weighted norms in SR3 classes computed incorrectly? #394
• Constraint specification is repeated across MIOSR, ConstrainedSR3, TrappingSR3. Maybe extract into a ConstrainedMixin?
• Two different ways to specify constraints (target or row) goes against ZOP 13 ("There should be one-- and preferably only one --obvious way to do it")
• Making the Trapping optimizer do less (by deferring to superclass) would make it easier to see the right way around Promoting Weak, PI, and Trapping to SINDy subclass #351.

I am starting to slim down what TrappingSR3 does, offloading work to the superclass. This will make all the follow-on work easier. But before I do all this, I wanted to hear from @MPeng5 what your plans were as they relate to library design.

[Jacob-Stevens-Haas]

What is the point of test_trapping_cubic_library()? Doesn't the trapping theorem require quadratic polynomials?

Also, does the ordering in PolynomialLibrary not match the ordering in make_constraints()? In Example 8, there's this nugget:

# Initialize quadratic SINDy library, with custom ordering 
# to be consistent with the constraint
library_functions = [lambda x:x, lambda x, y:x * y, lambda x:x ** 2]
library_function_names = [lambda x:x, lambda x, y:x + y, lambda x:x + x]
sindy_library = ps.CustomLibrary(library_functions=library_functions, 
                                 function_names=library_function_names)

[MPeng5]

@Jacob-Stevens-Haas Sorry Jacob, I was quite busy then but please let me join the discussion now. We come up with a new theorem which allows us to get rid of the make_constraints() in my version of Trapping. So let me know what your plan is right now. and as i mentioned from the other thread, we can discuss this on campus sometime.