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

That would mean downloading all headers from all peers. Initially, we don't know anything about our peers, and it is exactly _through_ getheaders (and a bit through invs, but that's harder to rely on) that we learn about what the peer knows. Usually, when sending an initial getheaders request to a peer, they already have the majority of headers we want, and using our own best will in the average case result in only a few 100 headers.