Mining hash / operation queues proposal

[johndpope]

needs some proper unit tests.
with the added queues x3 - we can reliably interject / cancel when other signals (block found remote / propagation) occur from block chain.

so the mining queue is basically the recursion to find next block.
the hashing queue is parallel threaded to determine hash
the block found queue I added as a sanity check to prevent two blocks being found at same time.
There's also a block found state variable to help orchestrate things.

you will notice that / they hang off the blockchain queue
the SynchronizedArray should prevent the underlying mutation of the blockchain data while all the threads are in action.

I've been testing and it seems stable.

eg.

var blockFound:Bool{
     get {
         return blockChain.queue.sync {
             _blockFound
         }
     }
     set {
         blockChain.queue.sync {
             _blockFound = newValue
         }
     }
 }

There's some delays that are added as bandaids which basically give the process some cycles on other threads to catch up.

eg
before we call mine - we sleep for a few milliseconds.
This delay variable value is more of an art that a science.

                usleep(Miner.bandAidDelay)
                 Miner.mine()

[vkoskiv]

Looks great so far. I'll do some testing and merge it ASAP if all looks good.

Just as a side note: I really appreciate you helping out with this project! This is the first time anyone has taken an interest in any of my projects at this level, and submitting pull requests for me. It really means a lot.

[vkoskiv]

A note on unit tests:
Feel free to make them. My philosophy with that stuff is basically: This code isn't mission-critical. Let's get it to a working state, and then worry more about proper testing and project structuring.