Override ToolSectionLabel.to_dict so don't need to_dict_helper.
I feel this is cleaner and it makes ToolSection and ToolSectionLabel easier to move into a new module.
Various ToolBox filtering improvements and tests.
 - Allow overriding the base module location for ToolBox filters (needed for OS packages, etc...).
 - Allow scanning multiple base modules for filters.
 - Unit tests for module loading functionality, custom tool, label, and section filters, default hidden and require_login filters.
Move galaxy.tools.watcher into galaxy.tools.toolbox.watcher.
Remove lib/galaxy/tools/filters/examples.py likely incorrectly added in d816d66.
Move galaxy.tools.filters to galaxy.tools.toolbox.filters.
Leave empty module in galaxy.tools.filters and modify config to ensure backward compatibility (filters in this old directory will continue to work for now).

Update config/galaxy.ini.sample with more discussion of ToolBox filter.
Improved unit testing support for ToolBox tests.
Allow multiple tools with the same id in ToolBox.

How to use:

 1.) Place multiple tools with different IDs in your tool conf.
 2.) ... ummm ... no step 2 - just use the tools.

Implementation:

The Tool Shed allows tool lineages by assigning each tool version a GUID and tracking versions in a database. This
implementation works by simply allowing the ToolBox to contain multiple tools with the same ID and orders them by the version specified by the tool author.

To track enable this a second tool lineage has been introduced that just uses tool versions instead of a database (non-toolshed installed tools are not longer placed into the Tool Shed install database). The ToolBox has been updated to allow multiple versions per tool id (defaulting to the 'latest' version for all operations which do not specify a version).

Unit tests working through most of the ToolBox and tool panel have been added, as well as functional tests exercising the Tools API. Manual tests against the new tool form seem to demonstrate the tool switching and tool re-running work with only minor changes to the tools API and the job handler.
Introduce ToolPanel abtraction.

There are some repeated operations on an odict in Toolbox that could be cleaned up (fewer lines of code, more readable) with new abstraction in place. Starting with __add_tool_to_tool_panel but will work its way to other methods in Toolbox eventually.

Abstraction reduces cyclomatic complexity of Toolbox.__add_tool_to_tool_panel from 23 down to 18.
Move more logic into ToolSectionElements, raising level abstraction in Toolbox.
Replace another repeated idiom in Toolbox with higher level method in toolbox.panel.
Move ToolSection and ToolSectionLabel out of galaxy.tools directly.

Would like to move the whole ToolBox out of galaxy.tools and into galaxy.tools.toolbox but need to separate all dependencies on galaxy.tools first.
Introduce HasPanelItems abstraction with several benefits.

 - Abstraction allows treating tool panels and sections more uniformly.
 - Using this abstraction for iterating over items eliminates isinstance checks (considered harmful - not ducky enough - http://www.voidspace.org.uk/python/articles/duck_typing.shtml).
 - Eliminates several direct references to the Tool and Workflow classes in ToolBox - (useful toward decoupling ToolBox from galaxy.tools).
Move 95% of ToolBox into its own module.

Including logic related to panels and sections, the integrated tool panels, labels, etc....

Leave a variant of ToolBox in galaxy.tools that needs to know about Tool runtime stuff (Tool creation, actions, and dependency management).
Rework galaxy.tools' galaxy.jobs import.

This version of the import I believe is less likely to cause circular import problems.
WIP: Test workflows with different tool versions.