Chain reorganizations which fail still reorganize to the partial chain.

[kayabaNerve]

This is invalid behavior, that should be resolved if nodes behave. That said, it coincides with https://github.com/MerosCrypto/Meros/issues/164, and also runs the risk of temporarily verifying/unverifying a transaction. This shouldn't happen thanks to Checkpoints, yet it's a concern.

We can either add a trusted field to the RPC, where if we're in the middle of a reorg, we say we don't trust TX status. This also can work when syncing up initially. That said, I truly consider this extra check an antipattern. We need to claim that every transaction that is up in the air thanks to a in-progress reorg isn't verified.

To summarize:

• If a reorganization fails, we MUST revert back to the fork point. It is NOT a requirement at this time to sync back up the original chain, as fixing #164 should have this happen within a minute or so.
• If a reorganization is in progress, we MUST return that no Transaction in the air is verified. This shouldn't be a security risk, thanks to checkpoints, but we truly need to be safe rather than risk being sorry. We can look into refining the selected transactions later.

[kayabaNerve]

Former is implemented and will be published in a moment. If the incomplete reorg still has more work, it's preserved. There's no reason to revert back in that case.

I have to decided to hold off on manipulating how TX verification is reported. Beyond being extremely hard to trigger, signatures should carry over (though #152 has its own commentary). Truly executing this attack would require the majority of Merit, which already breaks the system.

We still don't sync up the original chain, guarantee the validity of the other chain in advance, or blacklist the failure point. That is under the purview of #164.