Future proof dependency provider.

[Jacob Finkelman]

Most breaking changes in our API involve changes to the dependency provider. We can cut new breaking changes if we need to, but we would all prefer to avoid it. On the other hand, we don't want to at API service for functionality that is not yet implemented. We should look through future possibilities (that we can predict) and see if there are ways to change the API now to make things more flexible in the future.

Here are some additional functionality we may want add at some point:

1. The ability to add more different kinds of "dependencies" like constraints #124
2. The ability to return a borrowed iterator of dependencies instead of a owned Map #18
3. The ability to optimistically return a "no versions" incompatibility during prioritization #135
4. The ability to ask for a different package to be re-prioritized due to outside information #138
5. Provide statistics in should cancel about which packages are giving us trouble
6. I knew I had more in mind when I started this post...

Tools at our disposal include:

• adding new optional methods (which does not require breaking)
• having methods that return impl Trate so that we can add more implementations later (will be stabilizing soon)
• having our users construct wrapping types that we define, so that we can add more constructors in the future.
• Having arguments to our callbacks with types we control, that we can add methods to in the future.