Add d-leveldb (a leveldb wrapper library).

I'm not sure about using leveldb as redo's dependency database. It has a
major drawback which is I can't run multiple clients on it, unless I
write a writer daemon and set-up messaging myself. This breaks the
possibility of running several redo and redo-ifchange instances
concurrently right off-the-bat.

Still, I may choose to use it and work around the issues. I'd like to
discuss this at #2.
Start drafting using leveldb as redo's backend.

This is currently broken for some reason. Everything kind of works with
these changes, except running `upToDate` on a dependency recursively,
which means basic functionality gets broken by them. Also, for some
reason, the process now throws a segmentation fault error *after* redo
exists, which means the wrapper library probably leaves some C code
running and failing.

I think that it's probable leveldb may not be the solution I was
expecting to #2. Either way, here's a first run through how it'd be
used (even though to actually support everything and prevent processes
from not getting db LOCKs, the architecture would have to be quite
different).
Fix the segmentation fault at exit-time.
Update the directory structure and build process.

This new structure will enable us to write a comprehensive suite of
tests for redo using bed[1]. It is related to #2. This is an attempt to
battle test the approach I propose in bed using colorize and other
modules I plan to write. It enable us to get stricter about how our
implementation of redo behaves.

[1] - https://github.com/yamadapc/bed
Add slow but complete implementation.

The DB access bit is really messy and slow currently. Everything else
(though not yet concurrent or as general as I'd like) seems to work as
expected.

This closes #7, closes #6 and closes #2 for now.