Decoupling gas price from payload size

As [discussed](https://ethresear.ch/t/on-increasing-the-block-gas-limit-technical-considerations-path-forward/21225), depending on the gas limit in effect the execution layer may create payloads larger than what the consensus network can carry, based on [max payload size limits](https://github.com/ethereum/consensus-specs/pull/4045).

This creates an unfortunate situation where block builders create payloads that are valid according to execution and consensus fork choice rules, but not valid according to consensus network rules, paving the way for network-based splits.

Several solutions have been discussed and we should eventually settle on one - this issue catalogues the top contenders:

### (a) Increase the payload size

https://github.com/ethereum/consensus-specs/pull/4041

`+` increases the "safe gas limit"
`+` simple, in terms of specification
`-` increases attack surface for network-based DoS/amplication
`-` coupling remains, just further away
`-` coordination problems, when done outside of a hard fork

### (b) Limit encoded total transaction size

From the max payload size, we can derive a "max transactions size" [easily](https://ethresear.ch/t/on-increasing-the-block-gas-limit-technical-considerations-path-forward/21225/9?u=arnetheduck).

`+` aligns execution layer with carrying capacity of consensus network
`+` removes coupling
`+` EL already knows transaction encoding and can trivially compute size
`+` flexibility in small vs large transactions
`+` bound can be "close" to CL limit - no extra safety margin needed
`-` requires a coordination mechanism to express the limit (spec-based constant, CL informs EL via RPC, etc)
`-` requires execution layer mempools to be aware of byte limit, in addition to gas limit
`-` effectively acts as a second pricing dimension on transactions

### (c) Limit single transaction size

Currently, execution clients have no common "single transaction limit" meaning that some will accept transactions that others will not - the effect is exacerbated by private mempools whose rules are unknown.

`+` same as above
`-` still requires a max total transaction size
`-` inefficiently limits single transaction size (one large transaction is "cheaper" to process than N smaller ones with the same data)

### (d) Derive gossip limit from gas limit

`+` removes coupling
`+` community remains empowered to pick any gas limit
`+` single limit to rule them all, enforced by consensus/execution validity rules
`+` gas pricing can be used to adjust effective limit
`-` formula is complex to derive - depends on gas schedule, "best known method to create large transactions", gas limit update range over non-final chain portion
`-` dynamic "max size" is tricky to enforce during non-finality using present-day libp2p implementations
`-` community may choose a gas limit that the network is unable to carry (amplification, latency) or that breaks implementations (resource usage)
`-` increases DoS protection implementation complexity due to the variable-sized and unbounded nature of the limit

### (e) Max gas limit

See post [below](https://github.com/ethereum/consensus-specs/issues/4064#issuecomment-2552727089)