Feature/Single Pluggable DI Container

[asdacap]

• Follow up to Refactor/More proper use of DI for Synchronizer  #7500.
• Include Feature/network di #7520
• Add Enabled and ContainerModule to INethermindPlugin allowing plugins to extend components in a centralized manner.
  • The Enabled property is needed as the runner need to know if it should include the plugin's module or not.
  • The use of IModule enforces a convention where a plugin can use another plugin's configuration while only replacing some part of it, for example, the Optimism plugin uses the Merge plugin's module, replacing only the PoSSwitcher to its own implementation.
• Plugins have constructor with configs and chainspec available to it, meaning it is expected to be able to determine if it should be enabled based on the configs.
• IConsensusPlugin was removed, as plugin can replace INethermidApi via module.
• IInitializationPlugin was removed, as plugin can provide IStep via module and ShouldRunStep is basically Enabled.
• IStep is now resolved via dependency injection which allow its constructor to take on other component that need to run instead of just api.
• This PR is basically Feature/automatic dependency injection 1 #6483 with the exception of using a special registration source FallbackToFieldFromApi which allows dependency injected components to take component from INethermindApi.
  • This allow allowing code later in the initialization stages to use dependency injection without having migrate all compenents before it.
  • This allow some of the plugin interface to be replaced such as InitRpcModules, which does not sound much until you realize OptimismPlugin and MergePlugin have largely the same code!.

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Optional. Remove if not applicable.

Documentation

Requires documentation update

• Yes
• No

If yes, link the PR to the docs update or the issue with the details labeled docs. Remove if not applicable.

Requires explanation in Release Notes

• Yes
• No

If yes, fill in the details here. Remove if not applicable.

Remarks

Optional. Remove if not applicable.