Add support for multiple trees of the same type within a single discipline

[grantfitzsimmons]

This is one component of https://github.com/specify/specify7/issues/4640

Please see the issue for a more detailed write-up with additional considerations.

Trees

Because the TaxonTreeDefID (FK to TaxonTreeDef) indicates which taxon tree definition contains the names associated with an object, adding support for MOTs requires a fundamental change in the scoping hierarchy in Specify.

We would need to add the ability to view and switch between several taxon trees in a single discipline.

Because the trees would need to share a common schema configuration, the model I propose is to have it so that every tree is specific to that discipline, so even if there are 3, 4, or more trees in a discipline, they cannot be accessed outside that discipline.

https://github.com/specify/specify7/assets/37256050/0198fe8a-6269-4e2f-806c-286f8b8bf7d8

It could be as simple as a picklist that switches between the tree definitions so that the user can edit and view all of the trees linked to the various objects in that collection.

Specify could return all object types in the current collection and show only the trees that are connected to types in that list.

[realVinayak]

regarding query builder backend, this can be very simply (and naively) accomplished by passing the object type and getting the appropriate treedef here: https://github.com/specify/specify7/blob/4e5722aabb4ae3e8afd2ee487f4bea68eaff83d1/specifyweb/stored_queries/query_construct.py#L42 Figure out why it will "just work". the above assumes that defitems cannot be shared (like same rank ITSELF wouldn't appear in two trees). Like if Kingdom is treedefitemid=1 in one treedef, it is also not treedefitemid=1 in another treedef. basically, how the trees in specify works currently (so no worries I believe)

BUT, I think that'll be inefficient. You can make it considerably more efficient (think why the above isn't) very simply, by including the objecttype equality to the join criterion (well, technically just the first node, but you get the point) (https://github.com/specify/specify7/blob/4e5722aabb4ae3e8afd2ee487f4bea68eaff83d1/specifyweb/stored_queries/query_construct.py#L48)

^ofc that's for querying a specific tree. querying all trees at once is simpler (but I guess you can't say (any tree) -> species), like you could have (Fossil) -> species)

theoretically, doing something like (any tree) -> species is also straightforward (will think about perf impact). you could have an OR condition here (look up all treedefitemids which have species, put them in the OR below https://github.com/specify/specify7/blob/4e5722aabb4ae3e8afd2ee487f4bea68eaff83d1/specifyweb/stored_queries/query_construct.py#L56