Refactor ODE analyses through ODESemantics in catlog, catlog-wasm, and frontend

[tim-at-topos]

For some arcane GitHub reason, #1251 was automatically closed and I cannot reopen it. Then #1363 was a clone with #1319 merged in, but the automatic rebase that GitHub did with its new stacked PR feature messed everything up and broke all the tests. This is a third-time-lucky PR. I'll repeat all the original PR descriptions below for the sake of the reader.

---

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) subsequent PRs focussing on the front-end parts should now be possible, allowing for much more code removal.

---

Now that more ODE analyses have LaTeX equations, we should be stricter about the use of fmt::Display only for debugging.

This PR introduces some new types and traits (Latex, ToLatex, ToLatexWithMap) for dealing with LaTeX expressions and rendering object/morphism names nicely in the frontend. It also includes a bunch of tests for ODE semantics in the wasm layer. Finally, as a bonus, it removes a lot of repetitive code from catlog-wasm::src::analyses by defining ode_semantics_simulation and ode_semantics_equations, enabled by #1251, as well as removing some unnecessary types introduced there (such as LotkaVolterraEquationsData, which is just null).

Again, this refactor adds a lot of lines, but that's almost entirely due to how many nice new tests it adds 👼

As a bonus, this PR fixes the following issues:

• Stop using fmt::Display for LaTeX output #1171
• Polynomial ODE equations and simulation both show unassigned variables in compositional models #1215

---

Although further refactoring is possible (e.g. lotka_volterra.tsx and linear_ode.tsx share a lot of code), I think that the "correct" solution to this would be to start looking at generating that code from the definitions of the analyses rather than manually refactoring it. But this is now a much larger, rather separate project, so I think it's a bit out of scope.

With that in mind, I would suggest that this PR finally completes the last item in #1177 , and thus closes the RFC-0001 parent issue #1098.

[tslil-topos]

let's talk about this, but on the surface of things it seems to me that you should be able to do

pub trait ODESemanticsProblemData<P: ODEParameterType> {
    type EquationsData: ODESemanticsEquationsData;

    const EQUATIONS_DATA: Self::EquationsData;
    const INITIAL_VALUES: &'static [(QualifiedName, f32)];
    const DURATION: f32;

...

it's not typically possible to put a hasmap into a const, but it's easy enough to construct a hashmap from slices like this using collect.

[tslil-topos]

It's possible that i'll be able to answer these questions myself with more reading, but taking notes as they jump out at me.

maybe a follow-up question is: must this be a trait?

one could imagine a struct pattern like this

pub struct ODESemanticsProblemData<E: ODESemanticsEquationsDatat, P: ODEParameterType> {
  equations_data: E,
  initial_values: HashMap<QualifiedName, f32>,
  duration: f32,
  _param_type: PhantomData<P>
}

impl<E: ODESemanticsEquationsDatat, P: ODEParameterType>  ODESemanticsProblemData<E,P> {
  pub fn build_analysis(....) { ... }
}

and then we can figure out what extend_scalars is supposed to do?

[tim-at-topos]

i'm so silly, this should definitely be a struct instead of a trait i think

[tim-at-topos]

OK, I think I see the idea here. This would involve moving more things into the EquationsData than there currently are, but maybe that's not a bad idea... however, I think this would break all existing analysis documents, so we would have to finally do some sort of migration on this.

If what I've written isn't too unbearable, then it might actually be a good idea to stick with it.