Resolves #455
In a chain with #490

Allows an owner to "lock" some portion of value such that it cannot be spent except when specific conditions are met. This provides a programmable way to set aside some value for a specific purpose and to prepare value transfers to be completed by other public smart contracts (such as escrow and swap contracts).

New methods on Noto private ABI:

• lock(uint256 amount, bytes calldata data) - lock some amount of my Noto value and assign it a unique lock ID
• unlock(bytes32 lockId, string calldata from, UnlockRecipient[] calldata recipients, bytes calldata data) - unlock some value that I previously locked, and send it to one or more recipients
• prepareUnlock(bytes32 lockId, string calldata from, UnlockRecipient[] calldata recipients, bytes calldata data) - prepare to unlock some value that I previously locked, and record the prepared transition on the base ledger (but do not actually unlock)
• delegateLock(bytes32 lockId, address delegate, bytes calldata data) - delegate to another address that will be able to execute the prepared unlock operation (requires prepareUnlock to have been called)

Where the UnlockRecipient struct used here is defined as:

struct UnlockRecipient {
    string to;
    uint256 amount;
}

Some notes about these methods:

• It's possible some of the methods could be combined. You could make a case for lock + prepareUnlock or prepareUnlock + delegateLock or even lock + prepareUnlock + delegateLock, but for the moment I've left them all as separate transactions.
• I've also explored whether it should be possible to prepare multiple unlock possibilities at one time, but for now have settled on having at most one prepared unlock operation per lock.
• I did make it possible to unlock to multiple recipients in a single call (dividing it up as long as the sum is less than the total amount locked), and to unlock multiple times (you may keep unlocking value with separate calls until the entire value has been unlocked). We will need to decide if this flexibility is useful or if any of it is over-complicated. It also begs the question as to whether we need additional transfer variants for multiple recipients or batching, to match what is now possible with locking.
• Although unlock by default only allows the original lock owner to unlock the states, more complex flows can be implemented via Pente hooks. Particularly something like Exploration on contracts for NotoDepositWithdraw #485 should be possible, where one party locks some value and spawns a separate contract to track it (such as an ERC20), and then various other parties are able to claim portions of the locked value by presenting proofs of their entitlement to unlock it.

The unlock method on the Noto public ABI can be called via the notary, or may be called directly via a public transaction if an unlock operation has been prepared and delegated.

Domain receipts have now been implemented for Noto, allowing easy extraction of the following:

• All input/output/prepared states, broken down by regular coins vs. locked coins
• The generated lock ID (for all lock/unlock transactions)
• A pre-encoded unlock function call that can be used to run a prepared unlock (for prepareUnlock only)

This PR also removes the "NotoSelfSubmit" variant. This contract was not fully proved out, and it doesn't seem useful to continue adding features to it at this time. We can always bring it back in the future if needed.