Feature: Consider and document which log signature is propagated when checkpoints are combined

[mhutchinson]

When creating a merged checkpoint, combine_signatures.go#Combine currently picks the first checkpoint as the basis to which the other witness signatures are added. This means that the log signature on this checkpoint will be the one on the merged checkpoint.

In the case where all witnesses have seen the same checkpoint but the log signature was different (which could be because of a non-deterministic signing algorithm, or because of something like the timestamps that are embedded in the Sunlight CT checkpoint signature scheme), this means that we are arbitrarily picking a log signature to "win". From a quick look at the implementation, this arbitrary choice appears to be the log signature seen by the witness with the lowest ID as sorted by SQL alphabetically.

This behaviour isn't wrong, but it could be surprising. We should review this code and decide if we want something more stable. Ideas are:

• whichever checkpoint the distributor saw first
• whichever checkpoint was witnessed by the witness with the smallest timestamp