Introduce builder config containers

[StefanBratanov]

PR Description

Based on ethereum/beacon-APIs#630

Introduce BuilderConfig and BuilderEntry. I didn't want to change ValidatorApiChannel too much but instead make it backwards compatible with the new data structure. Next PRs would populate these fields correctly from the VC.

Fixed Issue(s)

related to #10822

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

Medium Risk
Changes the unsigned block production API and builder/MEV plumbing on the beacon node; behavior is mostly preserved via boost-factor mapping, but includePayload is not yet consumed and full builder config is not end-to-end wired.

Overview
Adds Gloas SSZ types BuilderConfig and BuilderEntry (aligned with beacon-APIs #630), registered on ApiSchemas, so proposer builder settings can carry min_bid, builder_boost_factor, and per-builder entries (URL, auth, pubkeys, payments).

Block production now threads Optional<BuilderConfig> through BlockProductionContext and ValidatorApiHandler instead of a bare Optional<UInt64> boost factor; execution/bid paths still read only getBuilderBoostFactor() for now.

ValidatorApiChannel.createUnsignedBlock gains includePayload and Optional<BuilderConfig>; a default overload keeps block v3 callers working by wrapping the old boost factor into a minimal BuilderConfig. Remote VC HTTP still sends only the boost factor until follow-up work populates the full structure from the validator client.

^{Reviewed by Cursor Bugbot for commit ebd827c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[lucassaldanha]

The changes look ok to me. But need to fix the mocking so we can get all tests to run.