sharding eip-1559-like behavior, with rolling-window adjustments

[protolambda]

Changes:

• Fee fields are for fixed-length shard data anyway (unlike dynamic gas count in eth1), account for it as total instead of per sample.
• The above enables Gwei usage for these fields, without losing as much accuracy for low-fee transactions.
• Base fees are tracked per shard, to avoid 1 fat shard and 63 slim shards from balancing out. Also increases predictability.
• Rolling window base-fee updates. A single base fee update is still very similar, but instead of processing once and moving to the next slot, we process with a lower maximum change, and repeat it for a few slots.
  • When there is a beacon gap slot, fees are stable, as the processing func is not called
  • When there is a shard gap slot, it accounts as 0, until it becomes non-zero with e.g. late inclusion. The effect of inclusion latency is minimized by spreading the adjustments, yet the base-fee keeps adjusting per slot, to not have to wait e.g. a whole epoch for adjustments.
  • When a beacon slot gap results in a late shard header, it is just one less adjustment step. Making the shard header fees less volatile, yet accounted for.
  • The exact quotient computation needs some work, just a rough guess how it could be like, the old one was outdated (per epoch, global fee instead of per-shard), corrections welcome. Might chart it out later, it's a starting point.
• Small bonus shard update: store the committee weight along with the voters weight, so we do not have to compute/cache committees and balances when checking confirmation progress. Especially useful for faster API service of shard data confs.

[protolambda]

Switching to gwei in base fee computation, over/underflows seem ok:

    Max prev_price is MAX_SAMPLE_PRICE, 33 bits.
    Max sample_delta is MAX_SAMPLES_PER_BLOB-TARGET_SAMPLES_PER_BLOB, 10 bits
    Max fee_delta_factor is 33 + 10 = 43 bits
    adjustment_quotient is 5 + 2 + 3 = 10 bits
    TARGET_SAMPLES_PER_BLOB = 10 bits
    fee_delta is 43-10-10=23 bits

1 gwei worst case precision difference, per sample, per shard, per year: 1 * 1024 * 64 * 365 * 24 * 60 * 60 / 12 / 1e9 = ~ 172 ETH per year. Using uint64 everywhere seems to be worth that.