Actually specify Tendermint misbehaviour predicate

[cwgoes]

Needs to be clear. Not the same as evidence predicate in Tendermint, exactly.

[cwgoes]

• Misbehaviour = fork detection, but not just equivocation. Goal: if there is a fork, halt the light client. Prevent any packets based on data now considered to be 'bad' (>= fork height).
• Any case where a light client would have considered two headers valid
• Including where Verify would have returned true under bisection, but no longer does
  For this reason we must allow Verify from some past state to detect lunatic attacks.
• Could elect to use a threshold < 1/3, but give up progress
• Methods for recovery (un-freeze) with some administrative (governance) override? Would be nice to keep state around w/o creating a new light client.

[cwgoes]

I wonder if an optional "governance" role is helpful in IBC. There are several places where it would be useful - also in reverting invalid handshake states & freeing previously used identifiers - that we can't do safely in protocol without a 'fiat power'. Most chains will naturally have some form (whether validator set majority or explicit governance).

[cwgoes]

Note that we can create incentives for submitting e.g. earlier equivocations.

[cwgoes]

Call it "would-have-been-fooled" proof - @warner