Don't pass API key to datatype display method.

Some datatypes cannot take the keyword parameter and none of them should need it.
Allow tool repeat and conditional params to be used via the API.

For now, still using the flat format of web ui. So

{...
 "a_repeat_0|a_repeat_param" : "value"
}

instead of the more ideal:

{...
 a_repeat: [
   { "a_repeat_param": "value" }
 ]
}

To implement this, there is a new path through the tool state processing code that sets the state based on the supplied inputs instead of requiring iterative calls (one for each repeat addition for instance). To specify this path through the code, Tool's handle_input takes a new parameter 'process_state' that defaults to 'update' for previous behavior but can be set (and is when coming from the API) to "populate" to exhibit this new behavior.

There may be reasons to iteratively call the API and build up a valid state iteratively, so the behavior of the API should potentially be configurable by param (populate versus update). (Does anything use the API in this fashion right now? Trackster param exploration? if so this new behavior should not be configured to be the default).
PEP-8 fixes for test/base/twilltestcase.py.

Still hundreds of lines to fix.
PEP-8 fixes related to tool test parsing.
Refactor shared code in functional_tests.py into a method.
Small simplification to test/functional/test_toolbox.py.
Refactor tool test parsing logic out of Tool and into ToolTestBuilder.
Make formerly public methods in ToolTestBuilder private now that it does its own construction.
Refactor test data input setup logic out of TestToolBox into ToolTestBuilder.

Simplifying test_toolbox.py will hopefully make it easier to provide an alternative API driven option.
Refactor data staging and tool running logic out of test/functional/test_toolbox.py.

In a new twill specific interactor class, idea here is to proceed by implementing a matching API interactor class.
Upload a tool test's inputs in parallel.

Probably small optimization in most cases since tests generally have few inputs.
Inject master API key into functional test Galaxy.

Override or set external key with GALAXY_TEST_MASTER_API_KEY.
Break up verify_dataset_correctness in twilltestcase.py

Will want to reuse the core verification of the displayed dataset in the API driven case and will not need or be able to use the extra cruft related to checking UI, job state, etc...
Outline new API based galaxy interactor for functional tests.
First crack at GalaxyInteractorApi - working for simple tests.

Lots left to do likely - conditionals, repeats, composite uploads, pages(?).

Introduces dependency on Python requests package (needed-ish for API uploads).
Move test_toolbox's expand_grouping out into tool/test.py.

Would be good to merge these two implementations there at very least easier to reuse/test in its new home.
Simplify logic in tool test expand_grouping.
Expand 'inputs' when building tool inputs for API functional tests.

Code is in there for both flat inputs (the way the UI would submit them, and a nested tree structure. The nested tree structure will not work with the Galaxy API currently.