A Modular & Extendable Subgraph Using Apollo Federations

# Goals
1. Allow new DAOs to be launched without bloating the **base subgraph** (this repo).
2. Allow new Schemes & Constraints to be developed without burdening the **base subgraph**.
3. Be able to query data from multiple DAOs with a single graphql query.
4. Updates / fixes to **base subgraph** can easily be deployed, and all other dependents will updated / fixed too.

# Required Reading
[Apollo Federations](https://www.apollographql.com/docs/apollo-server/federation/introduction/)
[Gateways](https://medium.com/@aaivazis/a-guide-to-graphql-schema-federation-part-1-995b639ac035)

# Proposed Plan
1. Split the existing subgraph into two parts, **base-subgraph** and **dao-subgraph**.
a. **base-subgraph** stores all entities that are universal to all DAOs. These would all have to come from predefined addresses (universal contracts).
b. **dao-subgraph** stores all entities that are DAO specific. This project would take the form of a *subgraph template*, where the deployer would need to provide contract addresses for the contracts that should be watched (Avatar, Reputation, DAOToken, Controller, etc).
c. Ideally **base-subgraph** & **dao-subgraph** have no overlapping contract addresses they're watching. Doing this would help satisfy Goal # 4. This will require refactoring the schema to further decouple things.
2. Each DAO will have its own subgraph. This subgraph will be an instantiation of the **dao-base subgraph template** talked about in 1b.
3. 3rd party schemes, constraints, and voting machines will run their own subgraphs.
4. All of these subgraphs will be queryable through a gateway. To learn more about how a gateway merges data from all of the graphql stores, please read the "Required Reading" above.
a. use https://github.com/nautilus/gateway ?
b. 3rd parties could ask to be added to DAOstack's gateway, or they could create their own.