Fae needs proper tests

The only tests we have at present are the sample transactions and demos. These are incomplete and really only work for me because they don't specify precisely what they test.

It is probably complex to set up automated unit tests, so at first, we should write well specified and self contained end-to-end tests, essentially better chosen and scripted versions of the sample transactions we have now.

Each scripted e2e test should:
- have specific target conditions that it tests. It may do more but success is only judged by these conditions.
- be completely automatic, particularly with regard to transaction-specific parameters like keys and sequencing of related transactions.
- report the outcome interpreted, not requiring the tester to understand the intermediate activity. The intermediate transaction results should be shown as well, so that a failure can be debugged.

The test conditions should be worked out systematically before starting this task. For example, they could form a hierarchy like:

- basic api tests
- the `signers` api function
- should return a `Map String PublicKey`
- "role" names (map keys) should be exactly the signers listed in the transaction
- multiple roles may have the same public key
- the `signer` api function
- should return without error the key for its argument that appears in the `signers` map
- should throw the correct exception (typed) if the role is not present.

These look like unit tests but are e2e tests anyway because they will be tested by running transactions through postTX and faeServer. There are also genuine e2e tests, say multiple transactions:

- `Blockchain.Fae.Contracts` tests
- the `deposit` contact
- successive transactions by the same signer should be able to deposit a value and then withdraw it by calling that contact.
- should fail with the correct exception (typed) if the signers are different.
- should also work if the deposited value is backed by one, or multiple, escrows like a `Coin`.

Such multiple transaction tests should coordinate passing data from one to the next by using the json-format responses.

And so on. Once this hierarchy of complete them the tests may be begun. We should structure them within an existing test framework, though not necessarily one specific to Haskell, since many of the tests will only see the cli output.