Feature: support merging checkpoints that were received out of sync

[mhutchinson]

This is easiest to explain with an example timeline with two witnesses, A & B:

1. A sends checkpoint of size X
2. B sends checkpoint of size X
3. A sends checkpoint of size X+1
4. A sends checkpoint of size X+2
5. B sends checkpoint of size X+1

Asking for checkpoint with N=2 will give a checkpoint of size X, where a checkpoint of size X+1 should be possible.

The reason for this is that the distributor is optimized to only keep the latest checkpoint seen for each witness+log pair in the pool of checkpoints available for merging. If this is replaced before it is merged and promoted then it is lost forever.

There are a number of ways to go about fixing this, but they all risk making the size of the database unbounded in size, or increasing complexity. The current strategy is to wait to see if this appears to be a problem before taking on that risk/complexity.

This test case is covered in cmd/internal/distributor/distributor_test.go: TODO: N=2 can get historic version where both have been seen but not at same time