support retries in [[create]] & [[setup]] steps

If a contract deployment or setup step fails, the whole scenario deployment has to be scrapped; when you run it again and it works, the previously-deployed contracts will be effectively forgotten (though they're still in the DB).

**High-level goal:** When running `contender setup`, check the DB to see if all create/setup transactions were sent, and if not, resume the previous deployment and save to DB accordingly.

**Technical details:**

For [[create]] steps, you can look up the required entries by `name` in the `named_txs` table. This makes it simple to find the contract deployments that haven't been executed: just count the number of entries in `named_txs` for each `name` in the TestScenario's `create` steps. The steps that haven't deployed will have one less entry in the DB than the ones that have been deployed.

Achieving the "resume" effect for setup txs will be slightly more involved. [[setup]] steps don't require names, so we'll have to save new info to the DB. A new table may be in order:

`scenario_setup`

| key | type |
| --- | --- |
| id | SERIAL INT PRIMARY KEY |
| scenario_name | VARCHAR |
| rpc_id | INT FOREIGN KEY |
| successful_txs | INT |

> `rpc_id` links to the `rpc_urls` table in the DB.
> Because a scenario might be deployed on a chain multiple times (for no reason), the client must order SELECT queries by descending `id`, then identify the target scenario_setup by finding the first match of `scenario_name` && `rpc_id`

For each successful setup tx sent, increment `successful_txs` in the DB by 1. Then, to find where to resume after a failed run, compare `successful_txs` for this scenario to the number of [[setup]] directives in the scenario.