If the timeout fired (even just nanoseconds) before the deadline of the
next pending reply, the timer was not rescheduled. The timer would've
been rescheduled anyway once the next packet was sent, but there were
cases where no next packet could ever be sent due to the locking issue
fixed in the previous commit.

As timing-related bugs go, this issue had been present for a long time
and I could never reproduce it. The test added in this commit did
reproduce the issue on about one out of 15 runs.

Table.mutex was being held while waiting for a reply packet, which
effectively made many parts of the whole stack block on that packet,
including the net_peerCount RPC call.

Fix tests on windows

trie: hex fix

faster hex-prefix codec and string -> []byte

They were unused and their tests failed on Windows.

Not closing the table used to be fine, but now the table has a database.

miner, core: sort txs by price, nonce

core, miner: added difficulty bomb

miner: fixed worker race condition

miner: gas limit strategy, target 3141592 & def gas price 50 Shannon

fdtrack: hack to track file descriptor usage

jsre: leave out lines from history possibly containing passwords

cmd, core, eth: support for the olympic network

Package fdtrack logs statistics about open file descriptors.
This should help identify the source of #1549.

Added a --olympic flag which initialiser the olympic protocol settings

The disk stats file was not closed after reading.

The JSON-RPC server wraps TCP connections in order to be able to shut
down them down when RPC is stopped. This is rather scary code. Go 1.3
introduced the http.Server.ConnState hook for such purposes. We can use
this facility now that we depend on Go 1.4.

There are multiple reasons for the switch apart from making the code
less scary:

* the TCP listener no longer ticks every second to check a channel
* pending requests are allowed to finish after stopping the server
* we can time out idle keep-alive connections

Update ethtest default path for BlockTests

accounts: bump timeout in TestSignRace

core: added a running flag to prevent panics in the chainmanager

core: added default genesis block

When a user runs a freshly setup geth w/o a database initialised the
default genesis block is decoded and inserted in to the database.

Old transaction after resend was not removed from pool

This should fix the flakeyness.