feat: refactor ssload/sstore to JournaledAccount

[rakita]

This will help with perf as condition for account to be loaded will be not needed.

sload/sstore are moved to JournaledAccount for better accesss to it.

This does not solve foundry API problem where they need to directly inject storage into account. Maybe doing unsafe_sstore would be a solution, but will leave this for later.

[codspeed-hq]

CodSpeed Performance Report

Merging #3145 will degrade performances by 7.02%

_{Comparing rakita/journaled-account-storage (d3cf00a) with main (d0bb48e)}

Summary

⚡ 1 improvement
❌ 4 regressions
✅ 168 untouched

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	EXTCODECOPY_50	52.6 µs	55.6 µs	-5.43%
❌	EXTCODEHASH_50	43.1 µs	45.6 µs	-5.35%
❌	EXTCODESIZE_50	42.6 µs	45 µs	-5.23%
❌	SLOAD_50	33.3 µs	35.8 µs	-7.02%
⚡	SSTORE_50	49 µs	41.2 µs	+18.68%

[mattsse]

from precompile pov this doesn't provide any additional benefits because in there we can not contrain any types, so we'd need to write additioal dyn compat wrappers for this I believe @klkvr

[mattsse]

if these types are both coming from the JournalTr itself, shouldnt the JournaledAccount then just be generic over that?