registry: decide on architecture for grant creation + flow of donation funds

[Matt Solomon]

These are coupled, so putting them into the same issue

There are two ways donations can be handled:

1. Donations are sent to a grant owner's address as part of the donation transaction
2. Donations are sent to a FundManager type of contract, which is single contract that holds all funds and provides a claim() method for grant owners to claim their donations

There are three main ideas we currently have on what grant creation could look like. All can be combined with both donation flows above:

1. An incrementing grant ID that maps to a struct containing a payout address (this is the current approach used by POC, and it has the downside of being very inefficient and costly, since you need a storage read for every payout address)
2. Deploy a proxy wallet (see #54), where the proxy wallet address is the grant ID. This is nice because the grant ID is the payout address, but has the downside of making it costlier to enumerate all grants on-chain
3. Deploy an NFT, where the holder is the grant owner

I currently lean towards the combination of donation flow 2 + grant creation 3, because:

• leveraging en existing NFT standard (TBD which, see #614) has benefits for composability, and even means your grant could automatically show up in your wallet
• having all funds sent to a singleton contract provides flexibility in account where we can optimize gas and behavior

However, a bit more research/thinking on the tradeoffs is needed before making a decision