Diagrams of Meshes

Currently, bespoke boundary conditions are included through the `generate` function by masking. That is, boundary conditions are not automated. There are two ways that this is done:

1. Through the `generate` function, such as in `poiseuille` and `bc_debug`. Masks are implemented as bespoke operators.
2. Through collages, such as in `stokes_aswell.jl` [here](https://github.com/AlgebraicJulia/Decapodes.jl/blob/663c836c920103166b158c08990899f326bbe704/examples/stokes_aswell.jl) which uses UWDs to specify meshes with their boundaries. A collage is "manual" in the sense that users need to write functions for each boundary. (e.g, `left_wall_idxs` [here](https://github.com/AlgebraicJulia/Decapodes.jl/blob/663c836c920103166b158c08990899f326bbe704/examples/stokes_aswell.jl#L59)). Collages require the user to specify an additional Decapode with the boundary morphisms, a relation diagram mapping the mesh to its boundaries, as well as the resulting Decapode collage produced through `collate`.

Both methods require new functions implemented into `generate` to specify the indices of the boundary and apply the correct value.

We'd like a way of automating this process further. Through `FreeDiagram` and the `@diagram` macro in Catlab, we have the ability of freely-constructing a diagram. We can use this to build a diagram of meshes which stores a hierarchy of subobjects for meshes, including the original mesh as well as boundaries, their boundaries, etc. We can use this to programmatically select boundaries and apply boundary conditions.

We can implement `map` for Diagrams (if not currently implemented) to broadcast functions onto the mesh hierarchy. Rather than passing in a mesh to the compiler, we can pass in the diagram of meshes. This way, the relationship between meshes and their boundaries are sustained throughout the entire decapodes workflow.

Because boundary conditions are also enforced through the `generate` function, it makes sense to have the Mesh Hierarchy also carry around functions traditionally stored in the `generate` function; for example, while `foo` may be defined over the mesh $$X$$, `bar` may be defined over $$\partial_{top}X$$.

This is a large lift impacting most aspects of Decapodes, so this implementation will create a breaking release.