[WIP] execution: fix and optimise BAL warmup

[taratorio]

Several fixes and improvements (check benchmark results below):

1. We had a bug with reading the BAL in the warmuper: at tip the BAL bytes from a newPayload are inside the in-memory block overlay (not committed to MDBX yet), but our warmuper was opening new RoTx-es in AddHeaderAndBody and trying to read the BAL bytes from there so it would never see them - essentially our BAL was never read and used for warmup. The fix is to pass the overlay as a tx kv.Getter to it.
2. That fix then revealed another bug that we had - the warmuper was loading the same code for different addresses from the DB instead of checking in the code cache based on the code hash. Fixing this bug saved a lot of unnecessary DB code reads
3. Optimised work distribution across workers. Before 1 worker would get clogged with 1 massive account with lots of storage slots and become the bottleneck. Now such type of work would be split equally amongst all workers. Helped with SLOADs heavy benchmarks 20%.
4. Added an ENV variable to experiment with number of warmup workers
5. Added an ENV variable to experiment with blocking/async warmup (non-blocking was more performant)

Benchmark	Fixtures	Original main MGas/s	BAL warmup MGas/s	Final MGas/s	BAL delta	Code-cache delta	Total delta
Entire suite	1,461	74.658	66.099	76.323	-11.46%	+15.47%	+2.23%
test_account_access	1,100	67.887	57.617	68.668	-15.13%	+19.18%	+1.15%
Ether transfers	196	53.080	52.309	55.690	-1.45%	+6.46%	+4.92%
Same-key SLOAD	22	6787.420	6790.542	6986.064	+0.05%	+2.88%	+2.93%
Bloated SLOAD	22	548.260	650.954	658.534	+18.73%	+1.16%	+20.11%
Bloated SSTORE	44	210.992	217.919	220.158	+3.28%	+1.03%	+4.34%
Warm external-account query	77	2438.037	2412.058	2404.698	-1.07%	-0.31%	-1.37%

Relevant test_account_access modes, excluding overhead_baseline=True controls:

Account mode	Original main MGas/s	BAL warmup MGas/s	Final MGas/s	BAL delta	Code-cache delta	Total delta
SAME_MAX	122.220	49.903	129.748	-59.17%	+160.00%	+6.16%
MINIMAL	123.766	90.668	130.672	-26.74%	+44.12%	+5.58%
DIFF_MAX	29.336	28.814	29.439	-1.78%	+2.17%	+0.35%
JUMPDEST	29.395	28.650	29.164	-2.53%	+1.79%	-0.79%
Existing EOA	299.084	305.647	310.204	+2.19%	+1.49%	+3.72%
Nonexistent account	473.151	501.704	506.245	+6.04%	+0.91%	+6.99%

SLOAD breakdown:

SLOAD case	Original main MGas/s	BAL warmup MGas/s	Final MGas/s	BAL delta	Code-cache delta	Total delta
Bloated, missing slots	547.086	639.472	659.721	+16.89%	+3.17%	+20.59%
Bloated, existing slots	549.439	662.856	657.351	+20.64%	-0.83%	+19.64%
Same key, missing	6582.315	6844.493	7010.755	+3.98%	+2.43%	+6.51%
Same key, existing	7005.719	6737.435	6961.546	-3.83%	+3.33%	-0.63%

[AskAlexSharov]

Review of the BAL warmup change. One crash bug, and the lifetime fix currently moves work onto the critical path rather than off it.

Comments are ranked by severity. The first is a node-killer; the next three are behaviour changes worth deciding on before this leaves WIP; the rest are cleanups.

The three comments on the BAL fetch are one root cause seen from three angles: the tx owns the bytes, not the parsed structure, so only tx.GetOne needs to be synchronous. Hoisting the decode with it costs a multi-MiB RLP walk on every newPayload, escapes the if !dbg.ReadAhead gate, and — with no header.HasBAL() check — runs on chains where the feature cannot apply.