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

Indeed. Feel free to suggest better wording.

The reason is that we don't have a map from blocks to their successors, only backwards. That means that if there's a fork A-B-C and A-B-D-E, and we try to connect E (which fails at B), A-B-D-E are marked failed (and E is removed from tips), but C isn't marked failed or removed from the tip. This is detected as soon as we do try to connect C.