Schedule protocol cleanup hard-fork in preparation for forward-blocks

[maaku]

Unlike bitcoin, achieving scalability with forward blocks on tradecraft will require an eventual hard-fork. Thankfully however, forward blocks presents the ideal opportunity for deploying such a thing, as there is a consensus-visible trigger for real demand causing larger shards to create a backlog requiring bigger compatibility chain blocks to clear. However while forward blocks is still being written, every version of freicoin/tradecraft that does not support detection of and acting on this eventual hard-fork is a version that will be incompatible with the trigger of larger compatibility blocks.

Therefore, the responsible thing to do is to deploy the hard-fork in this and future releases of freicoin/tradecraft, to be triggered on a suitably distant date years into the future. Later releases will either push back this date extending the block size rules for additional time (which would be a soft-fork), or implement the real demand-driven detection and switchover logic.

As to the contents of this hard-fork, it will remove most aggregate limits other than block-size, since they become less relevant with the performance enhancements that come with enhancements pulled from upstream, and perform various other navel-gazing fixes. Most critically though it should bump up the maximum block size to the largest value the software is able to support (my guess: 32MB, which would be 128MWe, which means the largest post-segwit block would still fit in a single 128MB blkxxxx.dat file), and completely remove constraints on block difficulty.

Of course the actual fork will be far more constrained, using a flexible cap to slowly ramp up aggregate limits, and with a new, more responsive difficulty adjustment filter. But by simply removing limits or bumping them to the maximum possible after a time-based activation date, these older, pre-forward-blocks clients will still understand the compatibility blocks that are relayed to them, even though they don't know to enforce the more restrictive validation rules.

[maaku]

26 implements this. Note that some of the design parameters have changed. See that pull request discussion and the code comments for more details.

[maaku]

Merged.