Create an entire new dependency resolver to help solve #22 and #23 because, well, why not?

The new one tries to be simpler in that the work is split into more distinct steps.
Instead of returning a list of modules sorted into build-order, it returns a graph (a hash keyed by module name).

Additional functions are provided to:

• convert the graph into a sorted list of modules in build order
• walk the graph as a tree (for introspection)

The new approach for dependency resolution works in multiple distinct steps:

1. Resolve the entire set of modules, and construct the graph data structure
2. Break certain well-known dependency cycles due to imperfect metadata.
3. Check if any circular dependencies remain
4. Vote for dependencies, by which each module 'upvotes' its dependencies (directly or indirectly through transitive dependencies). This effectively creates a complete map of back edges for each module in the graph. The vote is used for sorting into build order: the more popular modules should get sorted first.

The new approach may be said to have the following advantages:

• It does not need to croak_internal() as often: errors can simply be dealt with by returning an error code/object.
• The graph structure is exposed and permits much better introspection of what kdesrc-build is doing with dependencies.
• Subjectively: by using distinct steps there is less seemingly unrelated interaction between various functions going on.
• It should therefore be relatively easy to write good unit tests for the functions without requiring much outside setup/mocking.