Incorporating GATlab more deeply

[kris-brown]

This is a big refactor - right now just a draft. The goal is to rely less on type dispatch and use explicit models from GATlab. This will ultimately address a number of persistent problems we've seen in Catlab over the years, including issues with empty lists and VarSets vs FinSets. It will still be convenient at times to use a Julia abstract_type to handle informal interfaces, but for things like different implementations of FinSets, different implementations of FinCats, etc. we will use a data structure with a impl field and a model field which controls how the implementation satisfies the desired interface.

It is a bit difficult to track the changes because this is also an appropriate time to restructure the files. I'll do my best to summarize them here (eventually). One idea I have is that the CategoricalAlgebra code that is category-agnostic could come first, and then subfolders related to Set-like categories and C-Set-like categories could come afterwards.

The goal is for only minor breaking changes, keeping the user-experience as unchanged as possible despite big changes under the hood.

The current status is that that (Fin)Sets/(Fin)Functions/FreeDiagrams/Limits have all been refactored to rely less on type dispatch. Next is FinCats, and after that it remains to be seen how much change the CSet code requires.

Changes:

• A Set's element type should not be part of the FinSet (or SetOb) Julia type.
• A TypeCat is a "Pair of Julia types regarded as a category. The Julia types should form an @instance of the theory of categories". This should be replaced with simply a model of ThCategory. Because TypeCat was the only subtype of Category{Ob,Hom}, Category{Ob,Hom} is now just a wrapper around a Model{Tuple{Ob,Hom}} that implements ThCategory.
• Remove is_hom_equal (not part of the ThCategory, doesn't get used anywhere in Catlab)
• ob(::Cat{Ob,Hom}, x) and hom coercions cannot be handled by dispatch if we are now allowing for multiple different categories with the same Ob and Hom.

[jpfairbanks]

@kris-brown what is the timeline around this? I could see how keeping this up to date with any Catlab changes is going to be a nightmare.

[kris-brown]

I'm working full speed on it now, I expect to be ready for review by end of next week (really depends on how many dependent packages on Catlab use implementation details that I wasn't expecting though)

[jpfairbanks]

Ok, let's block the devs meeting next week to talk about this and you can have some kind of document that describes the changes that we can go through together. Rather than just using traditional code review. Because this is basically doing a systematic change across the whole codebase