Don't pass API key to datatype display method.

Some datatypes cannot take the keyword parameter and none of them should need it.
Allow easier use of tool repeat and conditional params 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) like the UI or specifing a tool_state externally. To specify this path through the code, simply do not include a tool_state parameter when using the tools API.
When parsing tool inputs - distinguish between those coming from HTML post and those from 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.

TODO: Refactor state building logic out into its own class, too many variables are being passed around over and over at this point.
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. I am not sure I am enitrely comfortable with serving raw data this way, but I guess it is no worse than the existing /display route. This is marked as beta and there is a note that it may be dropped at some point in the future.
Fix specifing dbkeys with API uploads.

Essentially a redo of changeset 83103cff8757. In order to fix uploads when now history was specified, the only available dbkey allowed was '?'. As a result of that changeset, when uploading files via the API users could only specify '?'. Now the stock dbbuilds are also available - though builds in the history are still not aviailable (TODO) and user custom builds may not be available (TODO check this).
Fix bug preventing use of data tools inside of conditionals via API.
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.

Add mechanism to tool test parser code to determine which Galaxy interactor should be used ('twill' or 'api' are current options). This maybe a stop gap to force usage of the API interactor until that becomes the default or may prove in the long term to be essential if there are certain tools that will always require Twill-specific functionality or if new browser-based JavaScript (e.g. w/selenium) are implemented. An interactor value can be specified at the tests level and/or at the level of individual test elements in the tool XML (using the 'interactor' attribute on either element).

The current default interactor is 'twill'. The default interactor app-wide can be overridden with the GALAXY_TEST_DEFAULT_INTERACTOR environment variable.
Twill-less tool tests initial implementation.

Implement GalaxyInteractorApi, is 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.