Preview: headers-first synchronization

Here's a first (well, second) version of a fully-functional headers-first synchronization. It's not ready to be merged (it breaks reindexing, which cannot deal with out-of-order blocks on disk yet).

Many changes:
* Do not use 'getblocks', but 'getheaders', and use it to build a headers tree.
* Blocks are fetched in parallel from all available outbound peers, using a limited moving window. When one peer stalls the movement of the window, it is disconnected.
* No more orphan blocks. At all. We only ever request a block for which we have verified the headers, and store it to disk immediately. This means that a disk-fill attack would require PoW.
* Some new fields in getpeerinfo:
  * 'syncheight': the height up to which we've validated this peer's headers.
  * 'commonheight': the height up to which we have all blocks in common with this peer.
  * 'inflight': the heights we're currently requesting from this peer.
* Require protocol version 31800 for every peer (released in december 2010).
* No more syncnode (we sync from everyone we can, though limited to 1 during initial *headers* sync).
* Introduce some extra named constants and comments.
* Several bugfixes:
  * CChain::GetLocator() didn't work correctly across the CChain end.
  * FindMostWorkChain() failed to remove the actually failed block from setBlockIndexValid.
  * ProcessMessage() failed to act on ban/reject notices resulting from validation failures during the direct execution (CheckBlock, ...).

Something seems to be wrong with the stalling logic, judging from my debug.log output:-

2014-09-17 13:38:05 received block 0000000000000838ff0a36baecd1d4c07807ebc54a59e7e05dd4681839ba2827 (height:191655) peer=103
2014-09-17 13:38:06 Requesting block 00000000000004f2b85c51e890bd7a445d7cbb16469c38447ab557c07eaafdc2 (192679) peer=103
2014-09-17 13:38:07 Stall started peer=1032014-09-17 13:38:09 Peer=103 is stalling block download, disconnecting
2014-09-17 13:38:09 disconnecting peer=103