Utilize tool test runtime tree analysis earlier to more correctly determine which inputs are data params.

Turns out previous changesets attempting to separately disambiguate and supply implicit defaults for conditionals do not really work data inputs - because they are not recognized as dataset input params during parsing. Additionally, this change should eliminate any ordering requirements of tool test params - i.e. you shouldn't need to provide the test parameters in an order that makes it clear what branch you are on before suppling a dataset in order for the parser to realize it is a dataset.

Finally, this changeset allows deletion of a lot of code and creates some more robust abstractions.
Previous attempt to allow implicit defaults for conditional test params had many problems.

This rewrite has fewer.
Make disambiguate_cond more difficult.
Re-fix tool API for uploads coming through nginx.
Give tools.get_incoming_value a chance to mangle all keys and see if they appear in some other format. Thanks to @natefoo for detecting the problem, determining the source of the error, and describing the exact path through the code - i.e.  doing all the work.
Allow implicit use of tool default parameter values when using API.
Allow robust disambiguation of repeat statements in tool tests.

Imagine a tool with a repeat statement like:

  <repeat name="rinst" title="Repeat Parameter">
    <param name="int_param" type="integer" value="1" />
    <param name="float_param" type="float" value="2.0" />
  </repeat>

3 test instances overidding int_param default in all three, but leaving the float_param default in place for the first and last can specified as follows:

  <param name="rinst_0|int_param" value="4" />
  <param name="rinst_1|int_param" value="5" />
  <param name="rtnst_2|int_param" value="6" />
  <param name="rinst_1|float_param" value="4.0" />

This syntax can be mixed and matched with specifing conditionals and nested repeats, etc....

A previous changeset purposed a syntax like:

  <param name="rinst|int_param" value="4" />
  <param name="rinst|int_param" value="5" />
  <param name="rtnst|int_param" value="6" />
  <param name="rinst|float_param" value="4.0" />

Upon consideration, I have determined that this ambigious syntax is more difficult to reason about, leaves so much ambigiouity in place, and is harder to support - so it is not supported.

The following changeset will add "the right" way to do this anyway:

  <repeat name="rinst">
    <param name="rinst|int_param" value="4" />
  </repeat>
  <repeat name="rinst">
    <param name="rinst|int_param" value="5" />
    <param name="rinst|float_param" value="4.0" />
  </repeat>
  <repeat name="rinst">
    <param name="rinst|int_param" value="6" />
  </repeat>
Tree-like input specification in tool XML file.

Allow nestable <repeat> and <conditional> statements in test tool definitions.

For instance, imagine a tool with a repeat statement like:

  <repeat name="rinst" title="Repeat Parameter">
    <param name="int_param" type="integer" value="1" />
    <param name="float_param" type="float" value="2.0" />
  </repeat>

3 test instances overidding int_param default in all three, but leaving the float_param default in place for the first and last can specified as follows:

  <repeat name="rinst">
    <param name="rinst|int_param" value="4" />
  </repeat>
  <repeat name="rinst">
    <param name="rinst|int_param" value="5" />
    <param name="rinst|float_param" value="4.0" />
  </repeat>
  <repeat name="rinst">
    <param name="rinst|int_param" value="6" />
  </repeat>

Likewise, <conditional name="cinst"> can be used analogously though this is for grouping and disambiguation - does not allow multiple instances to specified obviously.
Lazy load tool test cases.

Running any tool test, will force everything in toolbox to parse out, but at least just starting Galaxy doesn't require parsing all test cases.
Small clean up of argument processing in functional_tests.py
Refactor interactors out of test_toolbox into base.
Simplify test composite history item naming using UUIDs.

It needs to be unique, so lets use uuids instead of a composite name counter to make the code more portable.
Refactor tools test param parsing for potential reuse in workflow tests.

They will be used in a slightly different context, but will need to describe inputs and outputs so lets reuse this code if possible. None of these methods used tool or self anyway, so they are probably more appropriate outside of ToolTestBuilder and ToolTestBuilder is now much more manageable.