Is your feature request related to a problem? Please describe. Currently, the alternative implementations of OP Stack components, apart from op-erigon and asterisc, cannot take advantage of the superchain registry. This creates a sharded collection of chain configurations, where components like op-reth, magi, hildr, op-besu, op-nethermind, cannon-rs, the Rust FPP, and whatever comes in the future that isn't written in Golang, cannot take advantage of this package.

Describe the solution you'd like Modularize the superchain registry such that it can be used by all OP Stack components, preparing for a future where our critical infrastructure is implemented in many more languages than just Go.

Ideally, this means defining a core implementation, preferably in a language such as C, C++, or Rust that is more friendly for interop, and then creating FFI bindings that enable several front-end APIs to be built for the library.

We currently need support for:

• Java
• Rust
• C#

Describe alternatives you've considered

1. Implement separate versions of the superchain-registry repository for each language that the OP Stack's core components are built upon. This would require a decent bit of duplicated code, increasing the possibility of divergent configuration between the implementations.
2. Create FFI bindings from the Go implementation. Go does not lend itself well towards being called via FFI, and Cgo is a bit horrendous to work with when the direction is <language> -> Go rather than Go -> <language>. It requires cbindgen to embed Go types and semantics into the C header, etc. Rather than doing this, we should choose a more FFI friendly language that is closer to C (or, even C/C++ itself) for the base implementation.

Additional context Modularizing the superchain registry will pay dividends in the future, offering a central, interoperable library for every OP Stack component to share the same configuration utilities.