(Small) performance regression due to BAL

[arnetheduck]

#3911 introduced a small performance regression:

https://github.com/status-im/nimbus-eth1-benchmarks/blob/819502a2cd118d0c249366e9a5dfb4a4e478937f/short-benchmark-history.csv#L51

It's probably worth taking a look to see what extra processing is being done that is due to BAL.

[Ayash-Bera]

Found the source in #3911. Every call to getStorage, getBalance,
accountExists, getCodeSize, getCodeHash, getCode, beginSavePoint,
commit, and rollback now evaluates vmState.balTracker.isNil.not — three
pointer dereferences (Computation → vmState → balTracker → nil?) on every
opcode, including pre-Amsterdam blocks where the tracker is always nil.

Cached the flag as a bool directly on Computation at construction:

result.balTrackerEnabled = vmState.balTrackerEnabled 

Hot-path checks drop from a pointer chain to a single field load off an
already-hot object. Left the vmState.balTrackerEnabled calls in
process_block, tx_packer, etc. alone ; those aren't in tight loops.

[jangko]

reopen, Need a benchmark