Address bonsai self-destruct stale code present

[garyschulte]

PR description

During an initial worldstate sync, a self-destruct that occurs between the initial pivot block and final heal pivot block will leave stale code in bonsai code storage. If subsequently the code is redeployed via create2 to the same contract address, the bonsai db will fail to roll code changes to the block where the redeployment occurs. This presents in a handful of ways such as 'worldstate not present' or 'unable to copy layered worldstate'.

Discussing with @matkt, since the repivot and heal process does not presently have an opportunity to 'heal' the code storage, and we should be able to trust the trielogs, this PR changes the rollCodeForward behavior to overwrite stale code if/when it is found. This should resolve #4784 and give the besu team an opportunity to revisit this in flat database heal work that is ongoing.

Fixed Issue(s)

addresses #4784

Documentation

• I thought about documentation and added the doc-change-required label to this PR if
  updates are required.

Changelog

• I thought about the changelog and included a changelog update if required.

[garyschulte]

Testing with a database that exhibited this error on block 16369752. A self-destruct for contract this occurred during the initial sync/heal phase of besu, and was subsequently recreated on the problem block which exhibited the "unable to copy layered worldstate" error:

https://etherscan.io/address/0x0000000000a1c1accd070e0003838859fe4f7046#internaltx

testing with main yields the error state with this database (empty optional returned for the worldstate)
testing with this PR yields no error and this log output:

...At Address=0x0000000000a1c1accd070e0003838859fe4f7046, expected to create code, but code exists. Overwriting.

[matkt]

LGTM if the tests prove that this can unblock the nodes without adding another bug