Correct sample value for migrated tool config.
Small simplification to tool_panel_manager.py.
Reused get_section method to hide ToolBox.tool_panel from install_manager.py.
PEP-8 fixes for various Tool Shed components.
 - lib/tool_shed/util/tool_util.py
 - lib/tool_shed/galaxy_install/tool_migration_manager.py.
 - lib/tool_shed/util/shed_util_common.py.
 - lib/galaxy/model/tool_shed_install/__init__.py.
Method to abstract away ToolBox.shed_tool_confs from tool_util.py.
Start a gradual process of referring to these as dynamic tool confs instead of shed tool confs. I would like like to make them more generally Galaxy-managed tool configurations and distinguish them from deployer-managed configurations - rather then having overtly ToolShed-only logic in ToolBox.
Method to abstract away ToolBox.tool_panel from tool_util.py.
Now only thing accessing ToolBox.tool_panel outside ToolBox itself is ToolPanelManager.
Reuse new ToolBox.get_section method in ToolPanelManager.
This is a higher-level method and eliminates a couple more places where Tool Shed code is directly acceessing ToolBox.tool_panel.
Refactor logic for removing tools from panels into ToolBox.
May seem sort of like Tool Shed specific stuff - but I think it can be reused elsewhere down the road. Regardless of this however as of this commit no external components directly access ToolBox.tool_panel or ToolBox.integrated_tool_panel - which I think is important - these should be internal details of the ToolBox (or newer modules it leverages).
Update calls to ToolPanelManager.get_shed_tool_conf_dict for clarity...
... in other words to note where index in the resulting tuple is not actually used. Doing this to enable hiding this implementation detail (index) from components in subsequent commits.
Update ToolBox.update_shed_config to use config_filename instead of index.
Seems a more robust index, simplifies ToolPanelManager, etc....
Simplifications for ToolPanelManager.get_shed_tool_conf_dict.
None of the components using this method are using the index any more - so eliminate it. Also introduce a new ToolBox method to hide the details of ToolBox.shed_tool_confs from this method.
Reuse new ToolBox.dynamic_confs method other places...
... to shield ToolBox.shed_tool_confs from other components including Tool Shed install models, shed_util_common.py, and install_manager.py.

After this commit - shed_tool_confs is only accessed directly by the ToolBox itself.
Abstract tool lineage handling out of ToolBox.
Start work on infrastructure to support tool lineages not defined within the tool shed install model.
Abstract out higher-level helpers in ToolBox for lineage reasoning.
Reduces code duplication slightly and simplifies __add_tool_to_tool_panel (cyclomatic complexity reduced from 20 to 14).
Fix unit tests for 7cee92f.
Bugfix: Apply tool panel filtering in workflow editor.
Bug originally reported by Eric here - http://dev.list.galaxyproject.org/Bug-Toolbox-filters-not-applied-in-workflows-td4662879.html (though this only fixes the superficial bug of them showing up in the workflow editor - and does not yet implement "strong" toolbox filters as requested).

This is actually a broader change that centralizes logic for listing out tool panel contents when displaying components to the user and the added filtering comes about from that. It also eliminates the last places Galaxy was accessing toolbox.tool_panel directly (in those mako templates).
Shield ToolBox details from Tool.
Better seperation of concerns.
Update attribute and method names in ToolBox to reflect encapsulation efforts.

Using ToolBox._xxx instead of ToolBox.__xxx because realistically ToolBox is still much to large to grok and so I imagine it will need to be broken up even more (base class focused on just the panel details perhaps - or mixins - etc...).
Hack to fix bug introduced in 806202d.

I may be trying to juggle to many competing branches working on same component.
Add classic hidden_data field to tool form