Properly handle GrandPa commit messages that aren't verifiable yet

[tomaka]

#846 implements processing GrandPa commit messages.
However, if a GrandPa commit can't be verified because not all blocks are known, we simply discard the commit.
It should instead result in downloading the unknown blocks and trying to verify the commit again.

In order to not have an unbounded queue of not-yet-verifiable commits, we should limit ourselves to two pending commits per peer: for each peer, the not-verifiable-yet commit with the lowest target and the not-verifiable-yet commit with the highest target.

Thanks to this, it will be possible for finality to ultimately progress whatever the situation, provided that at least one peer isn't malicious.

[tomaka]

This was done in #2400