[Idea Discussion] Open-Source OP Chain & OP Stack Forks Metadata Source

Opening up discussion for requirements / ideas for creating an open-source registry for any and all OP Chains & OP Stack Forks.

**Problem:**
Crypto data teams have a super hard time keeping track of deployed OP Chains & OP Stack Forks. Some chain deployers attempt to get in touch with OP Labs / OP Foundation, but otherwise this requires sleuthing through Twitter, blog posts, news aggregators, etc. Many people maintain their own lists with varying degrees of comprehensiveness (nobody knows how many production mainnet chains actually exist)

To solve for this, want to create a shared open-source resource for analysts, developers, educators, etc to identify OP Chains & OP Stack Forks with the relevant information about them.

See [Key Definitions for Chain Segments](https://community.optimism.io/docs/contribute/important-terms/#the-superchain)

**Goals:**
- Be the best "source of truth" for identifying metadata for OP Chains & OP Stack Forks
- Store relevant information for analysts (i.e. Name, RPC, Block Explorer, L1 Contracts, Chain Configuration)
- Make it SUPER easy to contribute to (i.e. easy to add new chains, easy to modify data, easy to add bespoke attributes)
- Make it SUPER easy to read from (i.e. if we input in yml, outputs are available in csv, json, sql, etc)
- Provide the necessary metadata for analysts to create chain segments (i.e. RAAS provider, DA Layer, other Config Changes, potential superchain compatibility)
- Be scalable, we don't want to have to re-do this if/when there are thousands of chains

**Existing Version(s):**
- op-analytics Repo [`chain_metadata`](https://github.com/ethereum-optimism/op-analytics/blob/main/op_chains_tracking/inputs/chain_metadata.csv)
- Dune Upload from OP Labs CRM [`dataset_op_stack_chain_metadata`](https://dune.com/queries/3109219)
- [superchain-registry](https://github.com/ethereum-optimism/superchain-registry) repo
- [superchain.eco](https://www.superchain.eco/ecosystem/chains)

**Other Inspiration / Attempts:**
- [L2Beat](https://l2beat.com/scaling/summary)
- [growthepie](https://www.growthepie.xyz/)
- [Kofi's Rollup Economics](https://dune.com/niftytable/rollup-economics)
- [OP Stack Data Dashboard](https://dune.com/oplabspbc/op-stack-chains-l1-activity)
- [ethereum-lists/chains](https://github.com/ethereum-lists/chains)

**Open Questions:**
- What are the top use cases for this? (_Non-Labs teams, please share!_)
- What fields do we need to track? What "requirements" should this have?
--
- What's the best input format (i.e. csv, yml), output formats to be available (i.e. csv, json, sql cte)?
- What is the right organizational structure? (i.e. one ecosystem/chain deployer can have multiple chains, there may be a gazillion chains)
--
- How can we "automate" parts of this? (i.e. identify new L2s via L1 contracts - somehow tie that back to metadata)
- What could/should be onchain?
--
- What's the process for accepting/rejecting/verifying changes?
- How do we incentivize chain deployers to "register"?