Refactor DatasetPath out into newer galaxy.jobs.datasets module.

Add unit test for DatasetPath class.
Eliminate input (hence all) path rewriting in TaskWrapper.

Extend concept of false paths to apply to inputs as well, use the rewrites implemented in TaskPathRewriter.
Rebase JobRunner's in_directory out into galaxy.util for reuse.
Break Cheetah wrappers out of tools.py to prevent circular dependencies.

Also is more work toward reduces tools/__init__.py to a more managable size.
Rework interface between jobs and tools.

Pull code out of job wrapper and tool for building and evaluating against template environments and move them into a new ToolEvaluator class (in galaxy/tools/evalution.py). Introduce an abstraction (ComputeEnvironment) for various paths that get evaluated that may be different on a remote server (inputs, outputs, working directory, tools and config directory) and evaluate the template against an instance of this class. Created a default instance of this class (SharedComputeEnvironment) - the idea will be that the LWR should be able to an LwrComputeEnvironment or something like it and send this to the JobWrapper when building up job inputs.

Add a unit test to walk through this evaluation process. Verify parameters are evaluated, paths are correct, and exec_before_job hook called.
Introduce dataset_path_rewrites to slightly simplify tools/evaluation.py.
Add rewrite_parameters (defaults to False) option to LWR runner.

When false the current behavior of the LWR is maintained and cheetah templates are evaluated as if the command will be submitted locally and then the LWR will rewrite the command and config files and transfer files as needed.

If this option is set to True, an instance of the new class LwrComputeEnvironment will be passed along to job_wrapper.prepare allowing the LWR runner to instruct with the tool evaluation process to use the remote paths for input, output, and config files during evaluation. This option feels less hacky - I am skeptical there are tools that will work this way that would not have worked the other way and this does have down sides such as forcing all input files to be transferred regardless of whether actually used in command or config files. This will hopefully provide an entry point for modifying behavior of tool data tables however.

tool_dir is still rewritten either way - this is a small point hopefully.