This lemma makes proving simple properties about the deployed contract
state of a contract easier.

Also use these from Congress.v

Contracts cannot create blocks and balance of undeployed contract is 0

Remove it from the contract's perspective for now.

- No longer require that block reward can be computed from height.
- Remove Chain's dependence on BlockHeader. Instead inline appropriate
  fields in Chain structure.
- Change step_block to use a BlockHeader now instead of manually
  specifying all the fields. The new BlockHeader now additionally
  contains the creator and reward of that block, so step_block in effect
  contains the reward.
- These refactorings means that the circulation proof changes. Introduce
  created_blocks to get list of blocks created by user, and prove
  instead that the circulation equals the sum of rewards in blocks.
- Rename "baker" to a more general "creator" globally

Versions are not used for anything and the comment is outdated.

This is much more realistic, as allowing contracts to efficiently access
transaction histories for all addresses is extremely expensive. To do
this, we
* Add an account_balance operation in Chain instead
* Change incoming_txs and outgoing_txs to compute transactions from
  traces
* Require implementations to give a proof-relevant trace, and rework
  proofs to use these, as necessary

This holds for reachable states without this, as proven in
undeployed_contract_no_in_txs.

A state being reachable means there is an execution starting from the
empty state, that ends up in the state.

- Remove 'prove' tactic
- Remove some duplicated tactics and make some proofs more efficient

Match on smaller expressions, making everything much faster. Also
optimize solve_single.

This proves a concrete property about any Congress contract deployed to
a blockchain. More specifically, we show that the count of transactions
sent out by any Congress contract will always be less than or equal to
the total number of actions it has receive in "create proposal"
messages.
Thus, this property is stated only over the transactions going in and
out to the Congress contract.
To prove this, we reason over incoming and outgoing transactions, the
internal state of the congress and also the actions in the blockchain
queue.

This split between cases only makes things harder.

These abstract the list structure of the trace away from the events, so
that a trace is now a CursorList of ChainEvent values. The ChainState is
a new type for the environment and queue.

This moves ChainStep and ChainTrace to type. The reason being that our
proofs will depend on prefixes of traces and it will be very useful (if
not required) to be able to match on the trace and the steps.
ChainBuilderType is changed appropriately: now, an implementation just
needs to prove that ChainTrace empty_env [] cur_env [] is inhabited.
Thus, ChainTrace can basically be seen as one particular way to order
the execution so that we reach a state. When it is inhabited, it thus
means that there exists a proper way to order actions so that we reach
the state we are in.

Since we will need to reason over specific inhabitants of traces, this
is required to prove many interesting properties by induction, as
explained to me by Danil Annenkov.

Get rid of the proofs showing that ChainStep and ChainTrace respect
EnvironmentEquiv. ChainTrace no longer respects this in the base case
(this was necessary to define trace_app).