When a chain reorganisation occurs we collect the logs that were deleted
during the chain reorganisation. The removed logs are posted to the
event mux indicating that those were deleted during the reorg.

Customizable protocol stacks

Makefile: add support for iOS cross compilation

jrse: fix #1082, fail if setTimeout/setInterval lack callback

cmd, crypto: updated web3

whisper: fixed broadcast race

Whisper's expire and broadcast loops happen in two separate go routines.
Whenever an envelope is being expired it's removed from the set of
envelopes and it looses all information about the envelope, including
the "known hash". After the envelope has been removed it can be
re-accepted by a broadcasting peer putting back the envelope in the set
of envelopes. Since the envelope broadcast loop is separate of the
expire loop expired messages may be broadcast to other peer, resulting
in messages **never** being dropped.

This PR includes an expire check before adding new messages to the set
of envelopes.

miner: bugfix where blockhash in receipts and logs is left empty

Update common test files

rpc/api, xeth: added signTransaction method

Makefile: individual platforms, configurable Go runtime

eth/downloader: fetch data proportionally to peer capacity

cmd/geth, cmd/utils: removed legalese

core, eth, miner, xeth: clean up tx/receipt db accessors

eth/downloader: don't hang for spurious deliveries

State and receipt deliveries from a previous eth/62+ sync can hang if
the downloader has moved on to syncing with eth/61. Fix this by also
draining the eth/63 channels while waiting for eth/61 data.

A nicer solution would be to take care of the channels in a central
place, but that would involve a major rewrite.

Unexpected deliveries could block indefinitely if they arrived at the
right time. The fix is to ensure that the cancellation channel is
always closed when the sync ends, unblocking any deliveries. Also remove
the atomic check for whether a sync is currently running because it
doesn't help and can be misleading.

Cancelling always seems to break the tests though. The downloader
spawned d.process whenever new data arrived, making it somewhat hard to
track when block processing was actually done. Fix this by running
d.process in a dedicated goroutine that is tied to the lifecycle of the
sync. d.process gets notified of new work by the queue instead of being
invoked all the time. This removes a ton of weird workaround code,
including a hairy use of atomic CAS.

Removed the legalese confirmation dialog. This closes #1992

core, eth, rpc: split out block validator and state processor

core/vm/runtime: added simple execution runtime

The runtime environment can be used for simple basic execution of
contract code without the requirement of setting up a full stack and
operates fully in memory.

This removes the burden on a single object to take care of all
validation and state processing. Now instead the validation is done by
the `core.BlockValidator` (`types.Validator`) that takes care of both
header and uncle validation through the `ValidateBlock` method and state
validation through the `ValidateState` method. The state processing is
done by a new object `core.StateProcessor` (`types.Processor`) and
accepts a new state as input and uses that to process the given block's
transactions (and uncles for rewords) to calculate the state root for
the next block (P_n + 1).

rpc/api: fix #1986, newIdentity autocomplete

crypto/secp256k1: verify recovery ID before calling libsecp256k1