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

I'm curious. Can we make it so that nodes are considered to be misbehaving if they inacurately report the number of transactions in a block? To do this, we'd need to keep track of how many txs are reported in the header by each node and then when the block is received, we check if it was being truthful and DoS the node accordingly. By ensuring this data is reliable we enforce the maximum usefulness of headers and nodes, and deter people from broadcasting incorrect headers. We also enable decisions to be accurately made based on the header information. Would this class as a protocol change? I'd hope not.