Buffer votes for blocks we don't know about

[JamesHinshelwood]

Votes can arrive for blocks we aren't yet aware of in (at least) two circumstances:

• If we disconnect and reconnect, we will download the blocks we missed, but nodes might send us their votes for the next block before we've received the missed blocks.
• Due to network latency, a vote for a block proposal could arrive before the block proposal itself.

Before this commit, the node ignores these votes and the network eventually recovers via a new view. However, this slows things down so we should recover faster if possible. Instead, we store votes for unknown blocks in memory and replay them if the block later becomes known to us.

The implementation is fairly straight forward but there are a few caveats and TODOs:

• The return type of Consensus::proposal is now more complicated, as it doesn't just return a Message::Vote any more. If the proposal results in some buffered votes being replayed and those votes form a supermajority, then the node can immediately propose the next block.
• There's nothing which limits the memory usage of buffered votes. A malicious node is perfectly able to send us loads of votes with non-existant block hashes, which we will store forever. I've raised Limit the amount of memory used by buffered votes #719 to resolve this.
• When applying buffered votes as a result of a proposal, they take priority over our own vote. This means we lose out on the cosigner reward. Prioritise our own vote before buffered votes #720
• The unreliability test could be improved to be more efficient and to assert a stricter condition on the network - Improve unreliable::blocks_are_produced_while_a_node_restarts test #721.

[theo-zil]

Mainly one question about messages sent after processing blocks during sync, and a couple of non-blocking minor nits/questions, otherwise all looks good