Fix coinbase-spend mempool inconsistency after reorgs

We were previously not removing transactions from mempool during reorg if they spent a coinbase. While this broke the mempool-invariant of safe-to-put-in-next-block it doesnt matter as mining code double-checks anyway (unless you're running with -debug or -regtest during a 100-block reorg, then you will assert-crash). This takes the expensive solution of checking transactions for this case during a reorg-off (these transactions will not be resurrected after the reorg completes, as they should, however), though alternatively we could redefine the mempool invariant to safe-to-put-in-next-block-but-may-include-immature-coinbase-spends (but only do so /during/ a reorg, not before or after, unless someone added an rpc or otherwise forced a reorg to a block, which we should probably add at some point anyway or so, see my mempoolfix2 branch for a maybe-ok proposal to implement that one instead).

Also includes a new block-tester which will crash master (because -regtest implies CTxMemPool::check, as does -debug).
People may wonder about this so this const_cast needs a comment why it doesn't break expectations; the resulting child cache is never flushed so it is effectively const, and we don't have a CConstCoinsViewCache that would make this explicit.