feat: new execution e4 for memory adapters

[Golovanov399]

This resolves INT-4116.

The main change is: access adapter inventory now has (one) dense record arena that is used for all memory adapter records.
One record describes an act of either splitting a memory block into chunks of size lowest_block_size (usually equal to current address space's alignment, except maybe on initialization/finalization), or merging a memory block from chunks of size lowest_block_size, given their timestamps.

Example: one record can look like "at time 123 and address (2, 28) take a block of size 32 and merge from blocks of size 4, their timestamps were [3, 1, 4, 1, 5, 9, 2, 6]". In tracegen this record will generate one row in Adapter<32>, two rows in Adapter<16>, and four rows in Adapter<8>.

To generate trace, which we do for all adapter chips at once, we currently just iterate over all records sequentially and write into the already allocated trace matrices. We could first do a sequential scan to find, for each record, which rows in the matrices it corresponds to, and then fill them in parallel. We could also create more arenas (namely one per (block_size, lowest_block_size)), and then each pair "(arena, adapter)" defines a constant number of rows in this adapter's trace matrix per record, which would remove the need to scan first. However, this is out of scope of this PR.

Reth benchmark: https://github.com/axiom-crypto/openvm-reth-benchmark/actions/runs/16029214229

[codspeed-hq]

CodSpeed WallTime Performance Report

Merging #1733 will not alter performance

_{Comparing feat/new-execution-e4-memory-adapters (31361a7) with feat/new-execution (9fafdbb)}

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

Summary

✅ 20 untouched benchmarks

[jonathanpwang]

don't need to change it, but using u32 instead of usize might allow the compiler to do some stuff more efficiently(?)

[Golovanov399]

I believe the compiler should be able to find that we usually essentially do address_space as u32 so it should treat it like u32, at least most of the time, but yes, I keep in mind that we probably need to unify those usize <-> u32 conversions more

[jonathanpwang]

LGTM, nice job!

[jonathanpwang]

Latest reth benchmark comparison: https://github.com/axiom-crypto/openvm-reth-benchmark/actions/runs/16016116215

[github-actions]

group	app.proof_time_ms	app.cycles	app.cells_used	leaf.proof_time_ms	leaf.cycles	leaf.cells_used
verify_fibair	(-2 [-0.2%]) 1,264	322,699	17,271,190	-	-	-
fibonacci	(-59 [-2.5%]) 2,324	1,500,277	50,589,231	-	-	-
regex	6,915	4,165,432	166,449,586	-	-	-
ecrecover	(+31 [+2.2%]) 1,422	137,260	8,174,585	-	-	-
pairing	(-30 [-0.7%]) 3,986	1,862,964	102,530,853	-	-	-

Commit: 31361a7

Benchmark Workflow