OP Stack Manager architecture to support interop

[mds1]

This design doc details an architecture for OP Stack Manager that ideally fits the modular interop use case expressed in #52 that we move towards in https://github.com/ethereum-optimism/optimism/pull/11189. It focuses on L1 contracts only. Our current deploy config and deploy script is a monolith, so here we break it up into 3 discrete steps, each with their own distinct inputs and outputs.

[tynes]

A thought here is to have the ability to generate a rollup.json from a view function on the OPSM, not literally returning the json file but something that returns the required values that end up in the json file, it could be an update to the op-node command for generating config. This would create a cohesive story for OPSM tx -> operating L2

[tynes]

The usage of toml makes sense to easily operate with the superchain registry

[mds1]

Summary of design review call is we have general agreement on the design proposed. The following points and comments will be incorporated into the document:

• All forge scripts should have 2 ways of interacting with them: One way that takes a config filepath (this is what chains will use), another that takes the config object directly with file IO (this is what go e2e will use).
• Similarly, we should enable the same flexibility for outputs, both output file based and return data based
• When talking about how frequently a step occurs, clarify that in dev/testing the steps occur every time vs. in production where some steps are rare
• The paused variable must be part of the interface for dev/testing, but we should have it default to false so it can be hidden from users
• It's TBD whether M0.5 elegantly handles nonstandard features like CGT and Alt-DA
• Consider mocking the FP system as a way to reduce scope for M0.5. It still needs to be implemented in M1, but this may help ship something usable for interop sooner

[mds1]

All feedback incorporated in 117da12, @tynes this is now ready for final review + merge