Refactor ODE analyses to build models in the theory of signed polynomial ODE systems

[tim-at-topos]

This PR includes a massive redesign of the way that we handle ODE semantics, which has the bonus of introducing some new capabilities (#1177) as well as (hopefully) making adding new ODE semantics in the future considerably simpler.

For those reading (or reviewing) this code, my suggested reading order would be:

1. ode::polynomial_ode::build_system_custom_parameters to see how we interpret models of th_signed_polynomial_ode_system as systems of polynomial ODEs
2. ode::lotka_volterra to see an example of the main chunk of defining an ODE semantics: giving an implementation for ODESemanticsAnalysis
3. ode::ode_semantics to see where all the actual new code is
4. ode::mass_action to see where things are still messy and need some extra finessing
5. The comments that contain the string FEEDBACK, where I have some specific questions / highlight specific problems with this design.

p.s. I know this PR adds quite a lot of code for something called a "refactor", but (a) I added a lot of documentation and some new tests, and (b) a subsequent PR focussing on the front-end parts should now be possible, allowing for much more code removal!

---

To-do:

• Replace the main chunk of PetriNetMassActionAnalysis::mass_action::build_system with polynomial_ode::build_system
• Replace the main chunk of StockFlowMassActionAnalysis::mass_action::build_system with polynomial_ode::build_system
• Refactor lotka_volterra.rs and linear_ode.rs to build an ODE system #1275
• Remove catlog::src::stdlib::analyses::ode::signed_coefficients.rs (and anything else)
• Create a bunch of structure for ODESemantics
• Refactor catlog::src::stdlib::analyses::ode::polynomial_ode.rs
• Implement ODESemantics for linear ODE
• Rename "linear ODE" to "CCL" internally (i.e. not to the user) (and justify this!)
• Implement ODESemantics for mass-action
• Refactor catlog-wasm::src::analyses
• Refactor catlog-wasm::src::latex (cf. Traits for LaTeX equations throughout analyses #1172)

[tim-at-topos]

@epatters Here's a problem: we cannot push the mass-action analysis for signed stock-flow diagrams through the theory of polynomial ODEs because we interpret negative links as negative exponents, meaning we'd need rational ODEs. For now, since I essentially made up the theory of signed stock-flow diagrams, I've just removed its mass-action analysis. I see two options:

1. Wait until we think about rational ODEs (probably not that far into the future) and then come back to fix this.
2. Implement mass-action as it was before just for the special case of signed stock-flow diagrams.

I'm in favour of 1, but would appreciate your thoughts.

[epatters]

Hmm, good question. What would be the code footprint of option (2), i.e., leaving the special-cased ODE analysis code for signed stock-flow as is?

[tim-at-topos]

For now it would be reasonably small, essentially just duplicating half of the current mass_action.rs. But it would get worse in future PRs, since one goal of this is to refactor a lot of duplicated code between Lotka–Volterra, linear ODE, and mass-action, so mass-action for signed stock-flow diagrams would have entirely unique chunks of code for each part of the analysis (core, wasm, and frontend).

[epatters]

For now it would be reasonably small, essentially just duplicating half of the current mass_action.rs. But it would get worse in future PRs, since one goal of this is to refactor a lot of duplicated code between Lotka–Volterra, linear ODE, and mass-action, so mass-action for signed stock-flow diagrams would have entirely unique chunks of code for each part of the analysis (core, wasm, and frontend).

Thanks for explaining. Though I'm not sure how to weigh the tradeoff between keeping existing functionality and maintaining a clean codebase, I tend to value the latter a lot and since you also seem inclined in that direction, I'd say go ahead and remove it.

[tim-at-topos]

@epatters and @tslil-topos this isn't quite ready for review yet, but all that's missing is some extra documentation and then some extra refactoring that I think I might move to a future PR because this one is already quite hefty. (Note, however, that the subsequent PR should hopefully remove as many lines as this one adds!)

Would it be possible for one of you to to start taking a look through this when you get a chance please? I think it's very likely that there will be substantial changes requested, and I'd rather put off writing documentation for things that are liable to change 😎 I've included a suggested path through reading the code in the opening comment of this PR!

[epatters]

Sounds good. I've marked this for review despite your caveats because that will help me remember it needs a review.