Handle event signatures consistently

[garious]

Currently we have an Event enum type that is either a Transaction or a Witness that a previously submitted smart contract is waiting on. In each field (Transaction, Timestamp, Signature), we see duplicate information, a from PublicKey and a sig Signature, but those signatures are not handled consistently by the SigVerifyStage or the BankingStage. Rather than handling those individually, as well as each new Event type that we add, we need the top-level data type to be a struct containing the PublicKey, Signature, and the signed data. This PR gets most of the way there by reducing Event to an enum with a single field, Transaction, and then replacing Transaction's contract field with a new instruction field containing a new Instruction enum with fields for spinning up a smart contract or applying a witness. It means that Transaction now has a clear definition, "an atomic client-defined set of instructions," and one that is consistent with both Distributed Systems and Bitcoin terminology.

The next step is to remove the Event enum, which after this patchset, only exists as a shim to minimize churn. Once removed, we'll see Entries containing a list of Transactions, not a list of Events. To extend the contract language, you'll add a field to the Instruction enum, and handle it in the Bank's process_verified_transactions() method. Duplicates will automatically be discarded and you can be certain the from PublicKey was from the entity that sent the message.

Fixes #236

[garious]

This is as much as can be done without deleting event.rs, so would like to merge it before moving on. The next commit is more invasive and will require tweaks to the offsets.