Switch testing framework from MAIN to new UNITTEST network

This is our third attempt to improve the testing framework taking into account all previous comments and suggestions. The two previous attempts are: pull requests #4688 and #4732.

Summary: For several reasons the current test framework does not allow to easily incorporate new unit tests that append specially crafted blocks to the blockchain using ProcessBlock().
After we proposed a solution in #4688 @gmaxwell and @laanwj suggested not implementing the changes because many files not directly related to the testing framework were modified by the patch.
In the pull request #4732 we implement @gmaxwell suggestion that the test framework should run under the RegTest network parameters and not under the main network parameters. It was discovered that 10 unit cases are designed for the MAIN net, RegTest inherits from TestNet, which has many differences, so switching is not simple nor desired. @mikehearn and @laanwj proposed using a special new network called UNITTEST to be as similar to the real net as possible. We implemented this final suggestion.

In this pull request we implement UNITTEST. We reintroduced the criticized possibility to disable PoW check, but we did it under Params().SkipProofOfWorkCheck(). This method is a const virtual function that returns false for MAIN net, so there is no possibility that it is switched to true, under normal circumstances. This change does not extend the attack surface in any way.

The child network UNITTEST overrides SkipProofOfWorkCheck() to provide the skipping functionality.
To allow test cases to modify network parameters, we've added the ModifiableParams() global variable and associated abstract interface, with setters. These setters are only available if the current network is UNITTEST. Again, there is no way to modify the network parameters if the current network is not UNITTEST.

As in the previous pull requests, we've:

a. fixed the bug in miner_tests.cpp which leaves in the memory pool invalid transactions (mempool.clear() missing).
b. Added 7 unit tests:

ToCheckBlockUpgradeMajority (untested before)
EnforceBlockUpgradeMajority (untested before)
RejectBlockOutdatedMajority (untested before)
"bad-cb-height"
"bad-version"
"time-too-old"
"bad-txns-nonfinal"

Sergio Demian Lerner & Timo Hanke

No, it's not a bug. Receiving a single block can cause zero or multiple blocks to be connected, and ActivateBestChain's responsibility is just switching the best block whatsoever.

Feedback about failures causes a reject message to be sent to the peer, for which we remember the peerid. It would be useful to generalize this mechanism to have generic callbacks available about block validation (for example for BIP23 rejection reasons), which could also be used here.