Improved Decapodes integration: domains, meshes, initial conditions, plot variables

[epatters]

We can now do the Navier-Stokes vorticity equation in addition to the diffusion/heat equation. To accomplish this, we had to generalize the frontend support and Julia interop in several directions. A Decapodes simulation now analysis now requires that you specifiy:

• the geometric domain: rectangle or sphere)
• the mesh that discretizes the domain: several choices for both rectangle and sphere
• initital/boundary conditions for specific variables: again, several fixes choices available
• which variables to plot

The code is a quite raw in certain places and will need to be cleaned up later.

[github-actions]

Preview url: https://67528b1455da8aada6d7bfbf--catcolab.netlify.app

[quffaro]

This latest push anticipates more integrations with AlgebraicJuliaService more and, concretely, generalizes some code from the Decapodes integration. AlgebraicJuliaService specifies integrations in an AlgebraicJuliaIntegration ADT and then has submodules through a basic yet vague interface specify how they will build theories/models/diagrams for CatColabsumption.

While I do not think this is entirely complete, I've

• added a Geometry struct to contain the domain, mesh, and dualmesh.
• used ThDecapode <: AlgebraicJuliaIntegration to tag generic-sounding structs like Theory, which is currently mapping names to TheoryElements, which may be Obs or Homs each responsible for storing data consumed from the incoming JSON. This interface is vague but, barring one failing test for unrelated reasons, does not currently break functionality.
• threaded the system::PodeSystem variable further into functions, which allows us to carry more data further into functions, keeping the number of method arguments smaller
• housekeeping such as reorganizing code into functions and relevant functionality into distinct files, added documentation, cleaned up tests

I'd like to generalize the methods in Theory so that further integration points would have an interface they integrate with, but I'm not sure if these packages would require different data structures (specifically, would the fields of Theory be different, or can we can away with type parameterizing the struct by T<:AlgebraicJuliaIntegration?)

[epatters]

Thanks @quffaro! I like this reorganization and refactor.

[epatters]

Refactor is looking good, Matt! I know its WIP but I left some comments.