Dynamic destinations - pass job_conf.xml params to rule functions.

In other words, send extra job destination parameters to dynamic rule functions as arguments (in addition to those dynamically populated by Galaxy itself). This enables greater parameterization of rule functions and should lead to cleaner separation of logic and data (i.e. sites can program rules that restrict access to users, but which users can be populated at a higher level in `job_conf.xml`).

For example the following dynamic job rule:

    def cluster1(app, memory="4096", cores="1", hours="48"):
        native_spec = "--time=%s:00:00 --nodes=1 --ntasks=%s --mem=%s" % ( hours, cores, memory )
        return JobDestination( "cluster1", params=dict( native_specification=native_spec ) )

Could then be called with various parameters in job_conf.xml as follows:

    <destination id="short_job" type="dyanmic">
      <param id="function">cluster1</param>
      <param id="hours">1</param>
    </destination>

    <destination id="big_job" type="dynamic">
      <param id="function">cluster1</param>
      <param id="cores">8</param>
      <param id="memory">32768</param>
    </destination>
Dynamic destinations - allow dispatching on workflow invocation.

Generate a workflow invocation UUID that is stored with each job in the workflow and allow dynamic job destinations to consume these. Should allow for grouping jobs from the same workflow together during resource allocation (a sort of first attempt at dealing with data locality in workflows).
Dynamic destinations - easier, high-level reasoning about data locality.

... if only in a limitted sort of way. Provide ability to hash jobs by history, workflow, user, etc... and choose among various destinations semi-randomly based on that to distribute work across destinations based on these factors.

Add a stock rule as in the form of a new dynamic destination type ("choose_one") that demonstrate using this to quickly proxy to some fixed static destinations. Add examples to job_conf.xml.sample_advanced.
Dynamic destinations - easier, high-level reasoning about bursting.

Add utility to RuleHelper to simplify bursting reasoning slightly, setup a stock rule for bursting between two static job destinations - mostly for demonstration purprose but it might be useful in some settings.
Dynamic destinations - easier, high-level reasoning about docker tool support.

Added supports_docker function to RuleHelper for use in dynamic destination rules.

Add a very simple stock dynamic destination type (docker_dispatcher) that will send all jobs into either a docker enabled destination or a vanilla destination depending on whether the tool being mapped supports docker (at this time that means is annotated explicitly with a container id).