Checkpoints: The hash of the genesis block it's the genesis checkpoint #6230

It's nicer to have all the hardcoded hashes of the genesis blocks of the respective supported chains together. More importantly, all chains should have the genesis block as checkpoint. That way the checkpoint logic can always trust the first checkpoint and hopefully we will be able to save some if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock) here and there. I also add some tests to checkpoints. They're not very important since the asserts in chainparams would already detect any change in the genesis block, but it makes sure that "the checkpoint logic can always trust the first checkpoint". In fact, the genesis checkpoint is that is immune to reorgs, by definition. The genesis block is the first rule and the only true chain ID (because one based in names would require a memorable-ID system [and those are centralized and/or vulnerable to squatting]). (Shares base commit with #6229)

Added an alternative solution to the bug described in #6299. It may also solve #5984 (at least it shares some code with #5987) and maybe also other bugs related to not having a genesis checkpoint (the genesis block) in all chain modes.

Rebased after merging #6299. Apart from its original form, now this PR additionally has the a removal of the now-unnecessary check for the genesis hash block (and an additional big indentation commit). Let's wait for testing, I think it was safer to just merge #6299, but I truly believe the existence of a fully-trustable genesis checkpoint is the necessary step for decoupling the checkpoint logic from any notion of chainparams or a genesis block hash. I think I'm finding enough prove that problems can spring by not doing so and - still - this PR would be minimal if the enum-to-string was merged somewhere else (like in the currently closed #6229 or an improved subset of it) and ignoring the trivially-verifiable indentation.

Updated without adding any tests or sharing a commit with #6229. @sdaftuar Can you confirm that this also solves the problem you found, which was solved in #6299 ?

@jtimon Just looked at this, reindex.py fails, I think essentially for the same reason it failed before #6299 was merged.

Yes, @sdaftuar , you're right, this is no alternative fix of #6299 . I was testing it wrong, but fortunately qa/rpc-tests/reindex.py noticed, great! I removed everything but the single commit introducing the "genesis checkpoints", which @TheBlueMatt should like because he did the equivalent for alpha-0.10. If @luke-jr rebases #5987 on top of this I can close the PR.

In summary and to reiterate, there's no reason not to have the genesis block as a checkpoint: it's the best checkpoint you will ever have! by definition!

Closing for now. I will reopen again with the version with the tests. In the meantime @luke-jr can take this for his PR if he wants to.