Combine static analysis with pure manifest declarations to constitute depgraph

[sdboyer]

This one's been a long time coming, and is, I think, the last major hurdle.

At present, we only look at the dependencies declared by a manifest when determining what actual dependencies are needed. This has three obvious problems:

• There may be deps needed by the source that are not expressed in the manifest
• There may be deps expressed by the manifest that are not in the source
• There may be deps where some of their packages are needed by the dependee, but not all, and some of the unneeded packages may induce additional, unneeded deps

I'm not necessarily completely clear on the correct final answer to all of these questions, but it is clear that to begin answering them, we absolutely have to start including static reachability analysis in the solver itself.

[sdboyer]

It's also probably worth expressing the final set of packages actually used in the lock file. That doesn't entail stripping out unused ones, but it does make it an easy option, and even make it easier for post-cleanup tools like glide-vc (c.f. sgotti/glide-vc#14).

[sdboyer]

The first pass on this problem, #36, is probably not going to allow having different packages from the same project at different versions. Doing so shouldn't be a terribly hard addition later, but it involves even further changes to the algorithm's models and bookkeeping, and I'd rather roll those in a little later.

[sdboyer]

There are definitely follow-ups here, and I'm sure some bugs I'll find once I reintegrate with glide in Masterminds/glide#384, but the essentials here seem to be done, so closing this out.