Etherlink/Kernel: store gas price only once per block (or reboot)

What

In the Etherlink kernel, the gas price, which dynamically adapts to chain usage, is stored three times per block:

• just before the execution of the block (written to /evm/world_state/base_fee_per_gas),
• just after the execution of the block (written to the same path),
• when storing the block itself (written as the base_fee_per_gas field in the block).

The first one is only used in case of reboot in the middle of the block execution, in this MR we add gas price to the block-in-progress structure so that it's only written in case of reboot.

The second one is redundant with the gas price stored in the block, in the following MR !15609 (merged) we remove the /evm/world_state/base_fee_per_gas path in the storage and rely on the current block to know the current gas price. In !15593 (merged) we migrate the storage version to remove this path.

Why

The storage of gas price before the execution of the block seems to be the only case where world-state information is written during kernel execution without going through a safe storage. This MR removes this exceptional case to make it simpler to reason about world state updates, which is needed in the context of %Tezlink: two Etherlink chains on the same rollup to handle several world states.

How

Most commits are refactoring. The ones which affect the semantics of the chain are:

• "Etherlink/Kernel: add a BIP field for base fee per gas": modifies the format of block-in-progress (adds base_fee_per_gas at the end)
• "Etherlink/Kernel: don't store base_fee_per_gas at start of block": modifies what is stored in /evm/world_state/base_fee_per_gas during block execution (gas price at start of current block execution versus end of previous block).

Manually testing the MR

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR