Ensure reliability of withdrawal preconditions

[L-as]

We set a precondition on a state field on the outer account, which might fail, since it changes on commit. We could implement a poor man's action state and have two fields we switch between updating, once per block. Thus you can process your withdrawal safely on the following block.

[L-as]

This is trivial to do if we make a new account for every commit. We could set a long time limit (e.g. 1 month), such that after 1 month the account can be force deleted, recovering the account creation fee, cancelling withdrawals inside it.

[L-as]

We could also create a "wrapping" account that pushes it to its own action state, taking on the burden of matching the precondition.

[L-as]

One possible avenue is not putting inner action state in the app state and instead only recording it in the actions as is to be done for #158, but it is crucial that we can cancel withdrawals after an emergency pause.

A shitty work-around is making sure the delay is long enough that for 5 blocks (minimum 5 slots) continuously we can submit a new action state to completely flush the action state, but this is unreliable, because there is no guarantee that we will get 5 blocks in a timely manner.

Indeed, it could be in the block producers' interest to censure Zeko and collaborate in order to derive Zeko of its funds.

---

The more realistic solution is likely storing 2 or 3 inner action states explicitly. There are several schemes we could use, with less and more overhead. We could also store the max slot precondition at the time of the corresponding commit here instead of in an action as needed for #158 .