transaction logic for snapp transactions

[imeckler]

This PR implements the transaction logic for snapp transactions. Each snapp command has 1 or 2 parties (plus an optional fee payer). Associated to each party is

• an authorization (a signature, proof, or both)
• a predicate (a condition that must be true at the time of application, either a complex snapp_predicate or a nonce)
• an update (a series of modifications to that party's state, including changing the balance, snapp state, and delegate)

We can apply a snapp transaction by first processing the optional fee payer, and then for each party

• checking the authorization (this is done elsewhere, in the transaction pool and diff validation code)
• checking the predicate
• checking that the update is permitted according to the account's permissions
• applying the update.

[mrmr1993]

Looks good. The TODOs will need doing, but approving assuming they will happen layer.