Consider generating the config from a schema

### Problem description

Ref #9574

I'm looking through the docs in order to write a nix module for lodestar for ethereum.nix using nixpkgs RFC 42, and while doing so realized that while the pattern in the docs may work for trial and error as needed, it doesn't really give you a robust spec with all features laid out.

I ended up having to look at the code in order to fully understand it and write a compatible nix module. As time goes on, this means more human eyes will have to do the same just to keep the config options in sync. If a schema file were to exist, it could be used with a generator which produces the types at compile time, adding negligible overhead to the project, while making it much easier for downstream project to stay in sync with the config options.

### Solution description

I'm proposing using some kind of schema standard for the config which can produce the config types and their relationship, so that both nethermind and any configuration language can easily stay in sync.

### Additional context

The alternative is allowing things to break and handle breaking changes as they occur.

Start by comparing the configuration documentation with the implementation that the issue author had to inspect, then identify the full set of options and their relationships. Evaluate a schema approach that can generate compile-time types for Lodestar and support downstream configuration users; done means the schema and generated types remain synchronized with the documented configuration.

Written by the indexing model from the issue text.