Partially deprecate PoW `Block` handling

[greymistcube]

There is no real code path that is actually taken within IActionEvaluator for past PoW Blocks.

• In lib9c and above, evaluate calls are dispatched to other binaries, so it is not in use for production.
• Within libplanet, as there is no real way to create a valid PoW Block, the unit tests can't be really considered proper.

That is, we are dragging along what is essentially a dead piece of code more for show (and our own emotional comfort) but not for real substance. However, the following two functionalities must be kept.

• To be able to "read" PoW Blocks.
  • The word read is in quotations as reading of a PoW Block bypasses numerous validations and the said Block is not read in full (because Difficulty related properties are discarded).[^1]
• To be able to evaluate said PoW Blocks in lib9c and above.

In order to do so,

• [ ] Disable the native implementation of IActionEvaluator, i.e. ActionEvaluator, to be able to evaluate a PoW Block.
• [ ] Disable Append() for a PoW Block.
• [ ] Add tests codes regarding reading of PoW Blocks.

[^1]: Note that write is not part of the spec, as this is no longer possible.

[riemannulus]

To be able to "read" PoW Blocks.

In post-sloth, IMO, we don't need able to read old PoW blocks. After sloth, we can easily cut out the block's height and It does not make lower chain security. So, instead of being able to read PoW blocks, how about a re-genesis on the NineChronicles and drop out old blocks?

[greymistcube]

Several things:

• As far as I am concerned, forking the chain with a new genesis block of index zero is possible with or without the sloth update. The sloth update only makes it somewhat easier. Besides, whether and when it may be done is still only under discussion.
• This is only a partial safety measure to ensure that re-evaluation of a past block is possible (although I'm not certain if this is working as intended currently for 9c).
• Additionally, the current API is tied too much to past Blocks (and evaluations) and this is making a refactoring of API nearly impossible.
• Besides, additional tests in #3791 should have been added when moving to PBFT in the first place. 🙄