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).
Distinguish tool inputs coming from HTML post vs. JSON.

Most of the time they have the same value parsing rules right now, but the parsing rules for booleans would kind of hackish if applied to JSON clients (only a list with two values is considered true). Ultimately this could simplify from_html in DataToolParameter which has grown unwieldy.
Allow raw display of data via API.

Matching functionality available with sessions at /display in root controller. The test framework uses this functionality in root controller to read test result data so an API driven approach to testing will need to have similar functionality available.
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.
Twill-less tool tests fix for nested input filenames.