Fixed concurrency issue that allowed multiple miners instantiation.

[dzajkowski]

This PR is a refresh of #777

Description

Concurrent EthashConsensus.startMiningProcess() method invocation can lead to several miner actors.
There's no thread mutual exclusion and atomicity between AtomicReference.get() and AtomicReference.set() calls.

Proposed Solution

synchronized or ReentrantReadWrite is recommended to ensure that only one miner is created.
AtomicReference is redundant, since no CAS-related methods are used.
Solution assumes that no thread synchronization is needed when miner already exists.

[1015bit]

Any reasons to not turn EthashConsensus into an actor instead of using low level concurrency mechanisms?

[dzajkowski]

Any reasons to not turn EthashConsensus into an actor instead of using low level concurrency mechanisms?

I would prefer such a solution but after some digging I found that the reorg would touch a lot of code. this solution isn't pretty but it's small.
I will add a task to do a proper refactor of how the application is instrumented to avoid such runtime oddities.