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, ...).

Yes that is a concern. It's not more a concern than a peer currently
ignoring getblocks however when it is our syncnode. Eventually we'll learn
from other peers what the best headers are, when they announce a new block.
This is just to speed things up. It's always a compromise between bandwidth
and reliability. Sending the request to two peers will make it safer, but
also means downloading all headers twice in the worst case...