Badger Registry 2.0

### Context ###

Badger, in its constant seek of further decentralization of its ecosystem, developed the [Badger Registry](https://github.com/Badger-Finance/badger-registry). This Smart Contract, allows for a single source of truth of all Badger related contracts in a decentralized fashion. The Badger-Registry currently host a list of keyed smart contract addresses that includes all infrastructure and actors within the Badger infrastructure for each chain that Badger is on. Additionally, the registry hosts a list of all the vaults existing on each chain, keyed by their strategist (account that adds them to the registry) and mapped to their version type (v1 or v2) and to the stage at which they are at (experimental, guarded and production).

The current registry is deterministically deployed at the following address for all chains: [0xFda7eB6f8b7a9e9fCFd348042ae675d1d652454f](https://etherscan.io/address/0xfda7eb6f8b7a9e9fcfd348042ae675d1d652454f)

As Badger pushes for further decentralization and systematic efficiency, new requirements have come up for the Registry to the point where a new version is required.

### Requirements ###

A new version of the Registry Smart Contract must be developed based on the existing one linked above. The new version should include the following changes:

1. An initializable `strategistGuild` multisig account parameter. This actor should now be in charge solely of the promotion of vaults (changing vault status). This address should be modifiable from governance. Vault promotion should still be doable from the Registry's governance.
2. Add a fourth vault status (Index: 3, Status: Deprecated) - We want to be able fetch the status of all vaults from the Registry directly and populate the UI based on this.
3. In a similar way that vaults are keyed by their version (v1 or v2) we now also need to map metadata for each vault. This data should be passed when a vault is added in the form of a string (For example, adding a vault could look like this: `registry.add(Vault_address, "v1", "DCA-BTC-CVX")`). The metadata should be returned along with the vaults when calling the vaults view functions (`getVaults`, `getFilteredProductionVaults` and `getProductionVaults`).
4. Two way mapping for keys: Currently, addresses can be fetched based on keys (strings). A mapping of keys based on addresses is now also needed.
5. A function to be able to remove keys (Only callable from governance).

A brownie project is also required around the Smart Contract that includes:
- Unit tests (For all new and modified functions and storage)
- Integration tests (Does the thing work when used?)

Submissions will not be accepted if they don't compile or if they don't include tests.

### Post Bounty Offers ###

We may pursue the few developers that are able to undertake this challenge and succeed by offering 1-1 tailored bounties with the goal of onboarding them into Core Tech at BadgerDAO (Full time Contributor Positions).

### Dev-Discord ###

Feel free to join us on our Dev Discord: https://discord.gg/Tf2PucrXcE

Start with the existing Badger Registry Smart Contract linked in the issue and determine how its governance, vault status, view functions, and key mappings are organized. Build the required Brownie project around the new Registry version, covering strategistGuild, deprecated status, vault metadata, reverse key lookups, key removal, and unit and integration tests. Done means the project compiles and all new or modified behavior is tested.

Written by the indexing model from the issue text.