Test framework needs refactoring

_From @theoreticalbts on December 3, 2015 16:46_

Some tests their use own database, others use fixture. This is a sign that the fixture incorrectly assumes a single DB should be sufficient; we need a fixture that can manage multiple DB's.

Many methods have implicit inputs or outputs related to the `trx` field, which is effectively a global variable (ugh). For implicit outputs, see almost any `database_fixture` convenience method.

For implicit inputs, for example `create_sell_order` does not set the expiration on `trx`, so effectively its output expiration is dependent on the value of expiration at input.

Many of the methods of `database_fixture` are candidates for a reusable API that should exist somewhere else. For example, `cli_wallet` effectively duplicates some of the higher-level convenience methods of `database_fixture`.

_Copied from original issue: cryptonomex/graphene#469_

Start by mapping the test framework around database_fixture, its trx field, create_sell_order, and the overlapping cli_wallet methods. Review which tests use their own database versus fixtures. Done means the fixture can manage multiple databases, methods have explicit trx-related inputs and outputs, and reusable APIs replace duplicated convenience methods.

Written by the indexing model from the issue text.