Increase default -blockmaxsize/prioritysize to 750K/50K
Fix infinite loop with LogPrint on Windows

Running -printtodebugger -debug (or -debug=lock),
compiled with -DDEBUG_LOCKORDER would infinite loop
on Windows because every critical section lock/unlock
triggers a LogPrint.

Solution is to use the raw boost mutex instead of a CCriticalSection.
Use thread-local storage for LogPrint(category...)

This prevents crashes at shutdown where a global destructor
calls LogPrint(category...) after mapMultiArgs has been
deleted.
Add tests for correct and incorrect order of signatures for a multisig
(P2SH)
build: fix detection of boost libs on multi-arch distros

Fixes #3219.
docs: remove workaround instructions now that the problem is fixed
Merge pull request #3407

952fe2e docs: remove workaround instructions now that the problem is fixed (Cory Fields)
efdfee4 build: fix detection of boost libs on multi-arch distros (Cory Fields)
Merge pull request #3326

ad898b4 Increase default -blockmaxsize/prioritysize to 750K/50K (Gavin Andresen)
Merge pull request #3387

3e01c00 Add tests for correct and incorrect order of signatures for a multisig (P2SH) (Tamas Blummer)
update help for -blockmaxsize and blockprioritysize

- was left out in #3326
Merge pull request #3409

a9a37c8 update help for -blockmaxsize and blockprioritysize (Philip Kaufmann)
fixed documetation on hardening flags
Merge pull request #3411

08b93f9 fixed documetation on hardening flags (HaltingState)
Merge pull request #3377

0b238b2 Use thread-local storage for LogPrint(category...) (Gavin Andresen)
962b1cf Fix infinite loop with LogPrint on Windows (Gavin Andresen)
Move only: extract WriteChainState and UpdatedTip from SetBestChain.
Add ConnectTip and DisconnectTip.
Prepare block connection logic for headers-first.

This changes the block processing logic from "try to atomically switch
to a new block" to a continuous "(dis)connect a block, aiming for the
assumed best chain".

This means the smallest atomic operations on the chainstate become
individual block connections or disconnections, instead of entire
reorganizations. It may mean that we try to reorganize to one block,
fail, and rereorganize again to the old block. This is slower, but
doesn't require unbounded RAM.

It also means that a ConnectBlock which fails may be no longer called
from the ProcessBlock which knows which node sent it. To deal with that,
a mapBlockSource is kept, and invalid blocks cause asynchronous "reject"
messages and banning (if necessary).