BlockProcessor/BlockCache events cleanup

[bigspider]

This PR addresses two issues:

• classes wanting to listen to the "new_block" events would generally have to do something like blockProcessor.blockCache.newBlock..., which suggests a bad design. Moreover, the same classes (like the BlockchainMachine) typically also want to listen to the BlockProcessor's newHead event, and it was odd to listen to two closely related events from two different sources
• moreover, as the BlockProcessor only emits the new_head events after the service is started, there was the incoherent situation where the "new_block" event would be emitted by the blockProcessor prior to completing startup (while adding the block to the cache).

While the logic of the newBlock event is kept in the blockCache, the access to all the other classes (but the blockProcessor) is now granted via the blockProcessor via a proxy, that also makes sure that no events are emitted until the blockProcessor has completed startup.

[yahgwai]

Looks like the best solution. These classes are becoming really intertwined - would be nice to sort them out one day. Hopefully they work well now :crossed_fingers: even if they're complex.

Looking at this made we want some for more focused integration tests for the blockchain machine + processer. It would be nice to have a test that ensures blocks are never missed - even after shutdown/restart. I made a ticket for the future: https://github.com/PISAresearch/pisa/issues/374