Deku Indexer

We'll need an indexer soon.

Idea for Architecture

@EduardoRFS and I were thinking about this. It would be nice to keep deku-node is minimal as possible, making it easier to test and verify. To this end, one idea is to have deku-node only maintain the absolute bare minimum state (because we are using deterministic consensus we should only need the most recent finalized block). The archiving and indexing is done in a separate process, call it deku-indexer. deku-node communicates with deku-indexer via stdout or a message queue or something (we have to think about how to guarantee delievery while not compromising simplicity and performance of deku-node). We want independence between the two processes - I don't think DOS'ing deku-indexer should be allowed to affect deku-node, but at the same time it's important that deku-indexer receive the contents of every block from deku-node at least once.

No files, tests, or concrete entry points are named. Start by reading the proposed deku-node/deku-indexer split, then resolve the transport, delivery guarantees, and process-isolation requirements; the work is done when the architecture and integration boundary are agreed.