Aliasing and subgraphs

[jayrbolton]

• Add an aliases.yaml file that maps an alias name to collection names. This could be used by the RE API to abstract the collection names. We'll have to figure out how exactly we can use this in queries
• Add "subgraph" configuration files. This adds another set of names that group collections together into a set of vertices and edges connecting those vertices. Examples are GO, ENVO, ncbi_taxonomy, and GTDB

Expansion (not in this PR)

• I would like to also add a concept for types on top of subgraphs, which I'd call something like "blueprints". These would define a set of blueprint JSON schemas, collection aliases, and edge connections that a subgraph can conform to. This would allow queries, UI, and apps to work across multiple subgraphs.
• For example, you might have a blueprint called "taxonomy". Both ncbi_taxonomy and gtdb would conform to this blueprint. It would define some common document properties in schemas for the "taxon" and "child_of" edges, as well as the required edge connections for the subgraph.

[MrCreosote]

This seems reasonable without spending an hour or two thinking about it, but I suspect as you start using these files in code things may need to evolve

[MrCreosote]

Why an array?

[jayrbolton]

I imagine it could be useful an alias to expand out into multiple collections in a query