eth package creates new event mux

console: fix instance name printed incorrect on start

Makefile: enable iOS experimental builds (fix prev omission)

common: fix #2008, wrong hex prefix check

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.