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 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).
Clean up 4f7e715 slightly.
Merged in jmchilton/galaxy-central-fork-1 (pull request #256)

API Enhancements Required for API Driven Tool Testing
get_intiail_value history fix. Allows ToolDataParameters inside of repeats when using API.