feat: update L2 base fee formula

[Thegaram]

1. Purpose or design rationale of this PR

Update L2 base fee according to new cost estimates.

One nuance is that geth's codebase uses misc.CalcBaseFee in a few places to predict the next block's base fee. In our case this does not work. For example, after deploying this change on the sequencer, CalcBaseFee will diverge on the sequencer and follower nodes (until they upgrade to a new release). Cases where we use misc.CalcBaseFee:

• miner/scroll_worker.go: No change needed.
• core/tx_pool.go: Changed in this PR to use the current base fee. Follower nodes might manage txpool following a slightly inaccurate base fee estimation.
• eth/gasprice/feehistory.go: Returned next base fee might be inaccurate.
• internal/ethapi/api.go: Base fee returned for pending transaction might be inaccurate.
• eth/catalyst/api.go: Currently not used.
• core/genesis.go: Only used in genesis config, not relevant for us.
• core/chain_makers.go and core/state_processor_test.go: Tests.

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• feat: A new feature

3. Deployment tag versioning

Has the version in params/version.go been updated?

• This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• Yes

4. Breaking change label

Does this PR have the breaking-change label?

• This PR is not a breaking change
• Yes

[omerfirmak]

Will there be a seperate PR for L1DataFee changes?

[Thegaram]

Will there be a seperate PR for L1DataFee changes?

Those coefficients need to be updated in the L1GasOracle contract, they are not hard-coded in l2geth.