L2 Node: Observer assembles IC blocks

What

With instant confirmations enabled, Observer nodes now use their accumulated transactions to assemble the block instead of performing a full application of the incoming blueprint.

For a bit of context, current flow for observer incremental execution is the following:

1. Receive next timestamp
2. Update EVM context informations for future execution => Single transaction request is no longer a Noop
3. Receive inclusion preconfirmation
4. Execute transaction, write in durable storage, share result
5. Receive blueprint
6. Wipe accumulated state
7. Apply blueprint

What it should become with this MR:

1. Receive next timestamp
2. Update EVM context informations for future execution => Single transaction request is no longer a Noop
3. EVM context checks for potential sequencer upgrades
4. Receive inclusion preconfirmation
5. Execute transaction and share result
6. Receive blueprint
7. Wipe accumulated state Keep state
8. Apply blueprint Assemble with accumulated state
9. If diverge then perform Apply blueprint

Why

We're currently hindered by 2 major bottleneck w.r.t. block production and application:

1. Sequencer emits inclusion preconfirmations, but does not execute them incrementally => Large worker lock at the time of producing the block
2. Observer executes all the inclusion preconfirmations incrementally, but re-executes them when receiving blueprint => Duplicates lock number 1

Here we want to get rid of number 2.

How

1. 724cb91e => Layer interacting with assemble_block kernel entrypoint.
2. 4418ed73 => Factorize sequencer upgrade logic and run it inside the Next_block_info request.
3. 1b72e2d2 => Reuse the existing logic of apply_blueprint, AFAIU it already contains everything that needs to be done after calling assemble_block. Important : This statement needs to be reviewed (happy to peer-review this).
4. f3586706 => future_block_state no longer holds its own version of the state, we use the global session for this as we're now consuming it
5. 17dfafc3 => Broadcast Sequencer application resulting block hash
6. ecb74c70 => Share block hash through blueprint follower
7. 2be95e62 => Divergence logic inside apply_blueprint_store_unsafe

⚠️ Disclaimer

This MR requires:

• !20138 (merged) to fix divergence issues between applied blocks and assembled blocks
• !20157 (merged) to allow applied blocks after assembled blocks

assemble_block was not tested e2e before this, and we discovered a few semantic issues in the kernel entrypoint.