Layered config support with `config-rs`

[mempirate]

https://github.com/rust-cli/config-rs

[merklefruit]

I want to flag that we've had issues with config layers previously (see #308 and #316) because they added complexity when keeping configs up to date, especially when we have config files all over the place. Example:

• bolt-sidecar/.env.example
• testnets/holesky/.env.example
• testnets/holesky/commit-boost/.env.example
• testnets/holesky/presets/sidecar-delegations-preset.env.example

Touching a single variable requires updates in all these files + all the .gitignored ones we use in dev boxes or elsewhere.
Plus all external users of the sidecar for every release, paired with an upgrade guide explaining what we touched.

For the recent deployment, I spent a lot of time removing all minor inconsistencies between these files and thankfully I didn't have to adjust json, yaml or toml files as well just for the sidecar. This is why I don't think it's a good idea to introduce them now

Keen on hearing others' opinion!

[0ex-d]

A few suggestions:

• I believe centralizing the config variables in the workspace root would be a good approach (a single config.toml and .env for redundancy).
• For the testnets/holesky/* directory a symlink could resolve into other scopes (e.g bolt-sidecar) but it could add complexity across various systems (although we could fix this fs::canonicalize(config_path)? to nomalize).
  This would make it easier to manage configs and reduce duplication.

[merklefruit]

The problem with consolidating all these files is that there are small differences in the values provided in each, that's the reason they exist, for instance sidecar-delegations-preset contains the signing options to use a delegations.json file while others don't have them...

Very nice idea about the symlinks, I didn't think of that. For now I'd hold off on too many config changes though!