Tool Dependencies: Drop multiple tool_dependency_dir implementation for now.

Will reimplement once I have added more granular, plugin style tool dependency resolvers. They will benefit from there being just one default_base_path as implemented here, but allowing it to be overridden on a per resolver basis.
Tool Dependencies: Small clean ups.
Tool Dependencies: Begin rearranging arguments so all ones not of interest to every potential dependency resolution plugin can be kwds
Tool Dependencies: Finish refactoring toward generic keyword arguments.
Tool Dependencies: Introduce the concept of a dependency resolver, DependencyManager will check each in turn.
Tool Dependencies: Refactor common code out of _find_dep_versioned and _find_dep_default.
Tool Dependencies: Split package resolvers into Tool Shed and traditional Galaxy versions.
Tool Dependencies: Implement XML configuration of tool dependency resolver.

This is largely modelled off of @natefoo's job_conf.xml. This is a minimally configurable XML layout so far, but will be dding more options.

Already can decide between whether to load tool shed installed packages first (default) or manually conifgured ones. The advantages of loading manually configured ones first is outlined here - http://dev.list.galaxyproject.org/Test-Toolshed-Biopython-package-dependency-Atlas-fails-to-install-Was-Re-UnboundLocalError-local-var-tp4661765p4661879.html.
Tool Dependencies: Add ability to pass arguments to tool resolvers.

Use new functionlity to allow a much cleaner, more general solution to the problem outlined in Pull Request 220. Allow creation of a Galaxy package dependency resolver that always falls back to 'default' dependency. I think this should be the default last-ditch behavior if a specified version of a tag is not found, but I understand the desire for it not to be, hopefully making it optional in this fashion is an acceptable middle ground.

The original problem is essentially, tool shed installs require an exact version of package requirements to be used, but this very encumbering in rapidly evolving and/or non-toolshed use cases (e.g. my Galaxy-P production and development servers). It is tedius to keep different code bases, environments in such cases.
Tool Dependencies: Allow overridding the base_path on 'galaxy_package' tool dependency resolvers.

There was some code for doing this earlier but it wasn't configurable in anyway. This version looks like it should work and is cleaner.
Tool Dependencies: General clean up of test cases for tool dependencies.
Tool Dependencies: Modify the tool resolver syntax slightly.

<galaxy_packages /> looks better than <galaxy_package /> since it is a whole class of possible dependencies the corresponding resolver could resolve.
Tool Dependencies: Refactor actual tool resolvers out into the own module.

Cleans up lib/galaxy/tools/deps/__init__.py significantly and makes inter-dependencies more clear.
Tool Dependencies: Introduce higher-level abstraction describing dependency.

Passing the tuple (script, path, version) around is insufficient to represent other kinds of potential dependency load commands (namely module loads), this generalization allows more expressivity. I believe this abstraction also moves some logic out of the tool class that is better encapsulated in the deps module and submodules.
Tool Dependencies: Outline of integrating environment modules.

This is completely untested and undoubtedly needs some fixes. The point is large to outline how it could be done and let someone with interest in using this go in and flush out the implementation.
Tool Dependencies: Dynamically load tool dependency resolver plugins.

This largely mirrors the code for the dynamic job runner.

TODO: Merge this and dynamic job runners into Carl's plugin framework.