Check lastPreimage != nil before accessing the cached preimage

[mininny]

Description

The Fast VM implementation assumes the last preimage read has been cached, even if this is the first read. Moreover, the preimage key is always initialized to zeroes ([32]byte{}) while the cached preimage value is initialized to a null pointer.

That means if either there's an attempt to read the preimage value before writing a key, or if the key written is zero, an attempt to access the null pointer will cause a panic.

Neither scenario should happen in a correct Kona implementation -- reads should always be preceded by writing the corresponding key, and a key with zero value isn't valid. However this is the oracle's concern and should be delegated to it.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.89%. Comparing base (8ff9318) to head (1203fc4).
Report is 25 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #114   +/-   ##
=======================================
  Coverage   61.89%   61.89%           
=======================================
  Files          27       27           
  Lines        4091     4091           
=======================================
  Hits         2532     2532           
  Misses       1427     1427           
  Partials      132      132           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[refcell]

I'm not sure this is right - cannon doesn't perform this check - see here.

[mininny]

Yep, this is normally not needed, but the reviewers pointed out that this can result in NPE if a preimage read is not preceded with preimage write - just in case the client program misbehaves.

[mininny]

Also added a test here: 1203fc4 so that we can check the regression