Allow dynamic job destinations to consume UUID generated per invocation.

Should allow for grouping jobs from the same workflow together during resource allocation (a sort of poor attempt at dealing with data locality).
Allow dynamic destinations to reason about data locality at high-level...

... if only in some limitted ways. 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.

Added some stock rules and examples to job_conf.xml.sample_advanced that demonstrate using this to quickly proxy to some fixed static destinations - but the real utility here is probably using this as part of other, more flexiable dynamic job destinations.
Allow dynamic job destinations to more easily burst.

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.
High-level utilies for dynamic destinations to reason about docker support for tools.

Added supports_docker function to RuleHelper for use in dynamic destination rules and a very simple stock dynamic destination type that will sort 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).