EVM/Exec: bump nonce before execute transaction

What

As it says in the Yellow Paper :

Page 8 section 6. Transaction Execution : it states that, before a transaction is executed, it must pass a series of tests. Among these tests is (3) the transaction nonce is valid (equivalent to the sender account’s current nonce);

Page 10 under formula 90 "we assert that we have incremented the sender account’s nonce prior to this call, and so the value used is the sender’s nonce at the beginning of the responsible transaction or VM operation".

In the context of the transaction, the nonce must be incremented before executing the transaction, just like !11767 (merged).

Like it says in EIP-1052, the opcode EXTCODEHASH returns 0 if the account doesn't exist, as defined in EIP-161, but if the account exists and has no code, then the opcode returns 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470.I have ran a test with Anvil with an account with a zero nonce, balance and code.
When I create a contract and I compute EXTCODEHASH on ORIGIN the result is 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 and it says that the account exists. But the code and the balance can't be changed. The only way this could have happened is by the nonce being bumped before the transaction was played, because otherwise the result would have been 0.

NB : When creating a contract, it is necessary to calculate the new address by considering the nonce of the caller before this bumping.

0x323f60005260206000f3 = 

ORIGIN
EXTCODEHASH
PUSH1 0x00 
MSTORE 
PUSH1 0x20 
PUSH1 0x00 
RETURN

Manually testing the MR

stRandom2_randomStatetest642_data_index_0_gas_index_0_value_index_0: Failure -> Success
stSpecialTest_eoaEmpty_data_index_1_gas_index_1_value_index_1: Failure -> Success
stSpecialTest_eoaEmpty_data_index_0_gas_index_0_value_index_0: Failure -> Success
stSpecialTest_eoaEmpty_data_index_0_gas_index_1_value_index_1: Failure -> Success

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR