Refactor associated structures

[ScriptRaccoon]

This PR improves the way associated structures (e.g. the codomain of a functor, the right adjoint of a functor, the underlying category of a symmetric monoidal category, the ambient category of a morphism, etc.) are handled throughout the codebase.

1. The term "mapped structures" has been renamed to "associated structures". Likewise, "mapped assumptions" of implications have been renamed to "associated assumptions". This required renaming various tables in particular. This is consistent with the term "associated properties" already used before.
2. Instead of storing associated structures in separate tables such as functors, morphisms, and symmetric_monoidal_categories (e.g. to store the underlying category of a symmetric monoidal category), there is now a unified associated_structures table. It refers to the associated_structure_types table, which was previously called structure_maps. This was the main motivation of this PR because the previous tables did not formally interact with the structure maps table.
3. Only the categories table needs to remain because it stores the description of objects and morphisms of a given category, which is not an associated structure. (This might also be removed in the future by simply writing this information into the description field.)
4. Using this new approach, the display of associated structures on a structure's detail page has been completely reworked and simplified. The same applies to structures that are based on the current structure (e.g. functors that have the current category as their domain or codomain).
5. Both left_adjoint and right_adjoint are now also associated structure types. This makes it possible to handle adjoint functors without treating them as separate concepts. As a nice byproduct (and proof that this is the right approach), functor implications can now also have assumptions on their left or right adjoints. (At least, theoretically this works now. This needs to be explored in a future PR.)
6. There is now a distinction between required and optional associated structures. For example, the domain of a functor is required, whereas its left adjoint is, of course, optional.
7. These changes will simplify adding new structure types to CatDat. When adding, say, double categories (cf. Add support for double categories #290), it will be much easier to define the two underlying edge categories.
8. Dual and parent structures could theoretically be also treated as associated structures, but there are reasons to keep them as simple columns of the structures table for now.

Associated Structure Types

label	type	associated_type	required
domain	functor	category	TRUE
codomain	functor	category	TRUE
category	morphism	category	TRUE
underlying_category	symmetric_monoidal_category	category	TRUE
left_adjoint	functor	functor	FALSE
right_adjoint	functor	functor	FALSE

Updated database diagram

Click for a larger version. Interestingly, not a single table mentions functors, morphisms, or symmetric monoidal categories anymore. The support for them is entirely handled by the entries of the structure_types table.