Draft: Proto: Refactor removal of empty accounts

Context

Non delegated implicit accounts are currently deleted as soon as their total balance (including frozen bonds)
falls to zero. This behavior can have surprising consequences.

As a first example, consider an implicit account that injects a tx rollup rejection operation. After paying the fees the
account's balance is zero and therefore the account is deleted. But then the account is refunded thanks to the rejection
rewards. Hence after the operation is applied, the account still exists, but to inject new operations, its manager key
must be revealed again, which is inconvenient.

As a second example, consider two accounts A and B, and a no-op smart contract S. OT1H, the batch of operations
with the sequence "A sends its balance to B and then calls S" is not valid because A gets deleted after the first
step of the sequence. OTOH, the batch with the sequence "A calls S and then sends its balance to B" is valid. It
seems difficult to justify the invalidity of the first batch since it has the same effect as the second batch.

This MR proposes not to delete accounts while an operation or a block is in the process of being applied, but instead to
do so only after all operations of the block have been applied. This seems more reasonable since block application is the
transactional unit that updates the state of the chain. As was the case previously, an empty implicit account is deleted
only if the account is not a delegate, and does not have frozen bonds.

Fix #3209

Manually testing the MR

CI.

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