Consuming `/eth/v1/config/spec` as VC

We recently had some interoperability issues when new parameters has been introduced in the configuration.

As an example, when networking parameters has been promoted to [configuration parameters](https://github.com/ethereum/consensus-specs/blob/28e3c807e29f0125f6871fbc06ec3465597b8175/configs/mainnet.yaml#L106) caused VCs failing to start if upgraded before their BNs.

In Teku we recently merged a PR making the VC less `choosy` by following the new sequence when consuming `/eth/v1/config/spec`:

1. load local known preset (as per `PRESET_BASE`)
2. load local known config (as per `CONFIG_NAME`) **[new]**
3. load remaining params from remote

By applying known config by looking up `CONFIG_NAME`, the final configuration is guaranteed to have all expected params.

Wrt additional unexpected param (ie. upgrade BN exposing new configs, restart previous VC version) we just print a warning ignoring unknown params.

How are other clients do? If we all agree on a common strategy we could avoid interoperability issues.

Start by reviewing the `/eth/v1/config/spec` endpoint and the configuration-parameter behavior described in this issue. Compare how beacon clients consume known presets, known configurations, and unexpected remote parameters. Done means the clients agree on a documented interoperability strategy for handling newly introduced configuration parameters.

Written by the indexing model from the issue text.