Some PEP-8 fixes for lib/galaxy/tools/parameters/basic.py.
PEP-8 cleanup of lib/galaxy/tools/actions/upload.py.
PEP-8 cleanups for lib/galaxy/tools/actions/upload_common.py.
Break up row_for_param in tool_form.mako into smaller pieces.
Break up tools.handle_input - split out param checking.
Break up tools.handle_input - split out state creation.
Break up tools.handle_input - split out refresh state logic.
Break up tools.handle_input - split out page advance logic.
Break up tools.handle_input - split out actual tool execution intiation.
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).
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.
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).
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.