EVM/Kernel: SSTORE tick model is constant

Context

Once again the tick consumption backfires at us: while we naively tried to make a linear ticks per gas model for opcodes and hope it would stand, it is actually wrong for some data. Especially, SSTORE is not linear in ticks per gas but seems actually constant in ticks from the data we gathered. The CSV analysis produced with !11614 (merged) shows it:

opcode	no gas expected	cardinal	average t/g	median t/g	min t/g	max t/g	standard_deviation	total_gas	average_gas	total_ticks	average_ticks	ticks standard_deviation	inconsistent gas accounting
0x55		572	768.360438359053	205.3493103448276	17.1559	5627.41	1662.6252788600202	2930300	5122.902097902098	325597464	567242.968641115	59454.05077462044	2

Basically, the tick model of SSTORE seems to have an upper limit at 620k ticks with an average of 567k, and its standard deviation is about 60k.

Manually testing the MR

The model can be tested easily with the ERC1155 benchmarks:

node etherlink/kernel_evm/benchmarks/scripts/benchmarks/bench_erc1155.js > inputs_erc1155.json
./octez-smart-rollup-wasm-debugger --kernel evm_kernel.wasm --inputs inputs_erc1155.json --installer-config etherlink/kernel_evm/config/benchmarking.yaml

Without the patch the benchmark is broken (and the reboot doesn't actually works). Without the patch it works without any issue, and the result of the model is consistent:

> profile
...
[Debug] Estimated ticks: 1168967214
...
----------------------
Detailed results for a `kernel_run`:
%interpreter(decode): 1933736 ticks (4.825s)
%interpreter(link): 16 ticks (11.511us)
%interpreter(init): 46272464 ticks (24.643s)
kernel_run: 1087183347 ticks (9min42s)

Full execution: 1135389563 ticks (10min11s)
----------------------

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