Add a version field to block header

[akumaigorodski]

What is this for

This is a first step towards some kind of strategy for handling consensus-changing network upgrades.

It could look as follows:

• Whenever there is a change which affects the way a block hash is constructed we also update a version number.
• Older node disregards a higher version number and tries to validate a block according to its rules, it may or may not work; on failure we include a version difference in error message, which works as a hint that network has moved on and this node has been left behind.
• Newer node retains previous versions' validation rules and verifies a block produced by older nodes according to old rules.

This way upgraded nodes will still be accepting older blocks, but once a breaking version block hash is included in L1 all older nodes progression will effectively be halted with an appropriate error message.

I guess overall this is akin to hard-fork upgrade strategy where older network part is just commanded to upgrade to new rules by upgraded network part, because L1 agrees with an upgrade by including its block hashes. While this is inappropriate for L1 it may be a suitable strategy for a side-chain.

Why was this added

First practical example is #57 where one of the main goals is to introduce a fast full node sync based on header commitments to block txs, utreexo memforest, AMMs, auctions etc. while currently header only commits to block txs.

In future more UTXO types may be added as well as breaking validation rules may be introduced, which will be reflected in version number.