Integrate Tendermint consensus with the enclave

[Cashmaney]

At the moment, we have a few issues (of various degrees of impact) that arise due to the fact that the consensus mechanism doesn't help against taking nodes offline and trying to attack them if possible, or forging single messages in order to observe local results. #231 and #290 are examples, but there are others as well. Having to deal with this issue will cause contract creators to have a lot of headaches. Or, more likely, create contracts that are vulnerable to offline attacks.

If we created a way to make the enclave aware of the state of the chain outside it in some verifiable way, we could shut down the enclave, or prevent execution till the network is back up again.

Possible ways to achieve this -

1. Heartbeat between nodes. While this may seem simple, in reality it's probably the most complex solution, since reliable peer discovery and connection are non-trivial (especially in the p2p setting), and assigning a trust factor to Tendermint peers is also hard (we would want to trust a validator with a lot of stake more than a random node).

2. Move the block verifying logic into an enclave. My first thought is that this would require running Tendermint (or the entire application) inside an enclave. However, it might be beneficial to look into this a bit more, as there might a way to do it in a less intrusive way (e.g. using light clients to create points of trust)

3. Oracle. Pretty simple. Create a service that the enclave must ping before it performs any computation. Downsides are obvious - single point of failure, and performance impacts.

4. Create custom block validation inside the enclave (or rather, create a new block validator enclave). Instead of trying to perform the on-chain verification inside the enclave, we could consider a "L2" solution. This would be verification purely for the enclave, which could happen using non-deterministic methods. A simple algorithm for this might be something like (just an example, don't over analyse) - verify that at least 75% of the validators of the previous block signed the current block and that the block number is monotonously increasing.