Refactor the trait interface for finitely generated things

[olynch]

This compiles, but doesn't pass lints. The idea behind this refactor is that we should be more explicit in our traits about finitely-generated categories and double theory models. Specifically, "finitely generated" traits should expose actual implementations of FinGraph. This is in accordance with what "finitely generated" means mathematically for categories.

Default TODO list

• [x] Are all notable changes added to the changelog in dev-docs/?
• [x] Are there any manual checks that you did while preparing this release that could be automated and become part of the CI?
• [x] Are any relevant issues to the PR mentioned so that they will be automatically closed when the PR merges?

[github-actions[bot]]

Preview url: https://66d20a9b7f08f42523b2faf4--catcolab.netlify.app

[epatters]

@olynch, I realized that there is a conceptual problem with the new design that I didn't detect in my first review. The problem is that:

• The trait FgCategory is being thought of as describing bare categories (categories without extra structure) since object generators are identified with objects. Thus, it would not make sense to write, say, FgMonoidalCategory: FgCategory because in a finitely generated monoidal category, the objects and the object generators will not coincide.
• The trait FgDblModel should apply to models of double theories beyond discrete ones (or else what is the point of having a trait on top of the struct DiscreteDblModel), yet it extends FgCategory. But this means that it identifies objects and object generators, which won't be the case for double theories with nontrivial object operations.

I see two possible solutions:

1. change the scope of FgCategory by adding an ObGen associated type, or
2. have FgDblModel directly add the types it needs rather than extending FgCategory.

I'm inclined toward (1).

[epatters]

OK, for now I'm going to revert to using "Hom" to describe the external identities in a double theory. I'm open to revising this terminology in a future PR but it needs to be done carefully and consistently throughout the codebase and documentation, and the present state of this PR is quite far from that.