Begin headers-first synchronization

Many changes:
* ProcessBlock and AcceptBlock are split into ProcessBlockHeader and
  AcceptBlockHeader.
* Instead of 'getblocks', push out 'getheaders' to the sync node.
* Implement 'headers' P2P handler, causing headers to be included in
  the block index.
* pindexBest remains as pointer to the "current state of the UTXO
  set" (chainstate), meaning the point until where we are synchronized.
  pindexBestHeader is added as a pointer to the tip of the currently
  best known (and validated, except for transaction validity) header.
  pindexBest is guaranteed to be always an ancestor of (or equal to)
  pindexBestHeader.
* A new function SwitchToBestHeader finds the best header in the database,
  and switches to it. SwitchToBestBlock connects blocks along this best
  chain. These replace ConnectBestBlock.
* Actual blocks are only fetched along the known-best chain, using
  parallel block downloading logic in SendMessages. For each peer, a
  (bounded) list of requested blocks is maintained. New requests are
  sent asynchronously, as the requested blocks arrive. As the tree they
  belong to is already known, we can receive and store them out-of-order.
  This also means that the concept of orphan blocks disappears. If one
  peer stalls us, it is disconnected and the blocks requested from it are
  sent elsewhere. This is nicer both for us and for them.
* One exception to the headers-first syncing, is when we are fully synced
  (pindexBest==pindexBestHeader), and a new block 'inv' is announced. In
  this case, the block is fetched immediately ('getdata') without
  intermediary 'getheaders', to avoid the extra roundtrip. In case this
  received block does not connect, it is held in memory (just this one),
  until the blocks preceeding it are available.
* SetBestChain (which handled reorganizations) is no longer necessary, as
  SwitchToBestHeader and SwitchToBestBlock only ever connect/disconnect
  individual blocks. It is therefore replaced by two simpler functions,
  ConnectTip and DisconnectTip.
* In several places code is added to deal with the case that a
  CBlockIndex entry does not have corresponding block data available.

Advantages include:
* No more vulnerabilities related to orphan blocks, as they simply don't
  exist anymore. We only fetch blocks along the best chain, any other
  block we're not interested in.
* No more need for checkpoints to determine bounds on difficulties of
  received blocks, as we never receive a block without knowing its
  ancestry (or at least the headers for that).
* No more need for checkpoints for safety when disabling signature
  check. A rule like "Do not check signatures in blocks covered by
  N weeks worth of hash power" could be used, though this is currently
  not yet implemented. Checkpoints may still be useful as a blockchain
  lock-in, or as help for showing a progress indicator.
* The IsInitialBlockDownload() check can become very precise and safe:
  we're syncing a backlog as long as pindexBest != pindexBestHeader
  (not yet implemented).
* It can serve as a basis to implement SPV mode, which is basically
  the same logic, but with the blockchain-driven block fetching
  replaced by wallet-driven filtered block fetching.
* Efficient parallel block download, and generally avoiding many edge
  cases that were possible during the previous getblocks-based
  synchronization (including frequent duplicate downloads, orphans
  and and needing to wait for the next block to be announced before
  resuming). Additionally, the synchronization speed does not rely on
  guessing an initial peer to fetch from anymore - a single slow peer
  does not hurt you anymore. This also means that throttling upload
  speeds will not be a problem to the network anymore.

Potentially significant semantical changes:
* Only caching a single orphan (and only in steady-state) means
  that there are likely ways for peers to blow away our cache.
  On the other hand, it removes attack surface for memory exhaustion
  attacks.
* In case of a reorganization (not for regular new blocks that
  update the previous) to a previously unknown chain, an extra
  getheaders/headers step is necessary, potentially adding a slight
  amount of latency.
* In case a new best chain is known, but its tip blocks are not yet
  known, the best known ancestor of the new tip is used instead of
  the old tip. On the other hand, during this period it is known
  that we're not up to date. The effects of this on mining should
  be considered, probably.
RPC updates after header-first synchronization