feat(Wallet): add execution ordering via git-style branching

[fubuloubu]

What I did

Prior to this PR, we did not have a way of ensuring that Modify/Execute messages were executed in a specific order. This is important because there needs to be a way to ensure that we can enforce an off-chain ordering to the way that messages should be executed on-chain. The classical way of doing this would have been to use a "nonce" (self-incrementing integer value), allowing multiple messages to queue up at the same nonce height, allowing the ability to replace a badly-formatted transaction prior to attempting to commit it. However, this value also serves as an important representation of the transactions pending in the current queue (and their dependencies), and thus need to have a clearer correspondence to the intent of the proposer(s).

How I did it

Here we have implemented a branching-style, hash-based mechanism for off-chain ordering, where the EIP712 message hash of the last message to be committed is referenced in the message itself. This enforces a natural ordering to how messages must be committed, and also gives a few nicer capabilities:

• "canonical-ness" of the message hash (vs. nonce) as the chief identifier of the transaction (increasing the security of referencing these values when signing on embedded devices e.g. HW wallets)
• the ability to definitively reference a specific decoded transaction using content-based routing (e.g. IPFS)
• a more intuitive representation for how transactions are displayed (using branches)

There is however a cost when "replacing" a transaction from the middle of a branch of transactions intended to be executed in sequence, as the later transactions will have to be "rebased" once the replacement is added, which could be somewhat annoying to signers. However, this sort of enforces revisiting the transaction sequence to ensure they are still valid, which could have a benefit of avoiding further invalid transactions being committed.

How to verify it

The change is fairly simple, adding the method head() used to obtain the last committed transaciton. Module transactions (which bypass signature validation) do not use this feature.

Checklist

• All changes are completed
• Change is covered in tests
  - [ ] Documentation is complete