Add config and/or modify implementation of execution paths

[MattMcL4475]

Investigate and propose the changes required to make the batch script have the desired path schema for Terra:

Current:

https://test.blob.core.windows.net/sc-a617a56e-56a5-4a52-b4f0-895afa7ccbe8/cromwell-executions/assemble_refbased/0fb40b27-dffe-4d3f-b6da-02ea0b82aedd/call-align_to_ref/shard-0/execution/__batch/batch_script
/cromwell-executions/assemble_refbased/0fb40b27-dffe-4d3f-b6da-02ea0b82aedd

Desired:

https://test.blob.core.windows.net/sc-a617a56e-56a5-4a52-b4f0-895afa7ccbe8/workspace-services/cbas/wds-a617a56e-56a5-4a52-b4f0-895afa7ccbe8/assemble_refbased/0fb40b27-dffe-4d3f-b6da-02ea0b82aedd/call-align_to_ref/shard-0/execution/__batch/batch_script
/workspace-services/cbas/wds-a617a56e-56a5-4a52-b4f0-895afa7ccbe8

[BMurri]

My suggestion:

1. Drop cromwell-executions, executions, etc. as a TES thing. Those directories are, originally, a CoA thing that was piggybacked to solve the question of where to drop TES-generated scripts to bootstrap/control the executors. They can still be created in the CoA deployer as a convenience for Cromwell, but otherwise such a container is the purview of the deployment team integrating TES into whatever their solution happens to be.
2. Add a new container. Right now, ga4gs-tes's deployer creates one called executions and uses it assuming it's being called by Cromwell. I suggest a completely different name so as to enforce the concept that it's not simply a generic cromwell-executions. My (awfully named) suggestion: "tes-internal";
3. Inside of that new container, create a folder that is the TesTask.Id's value. Inside of that folder, stage the files(scripts) that currently go inside of the __batch folder way down at the bottom of each task in cromwell-executions. Those scripts will presume that the executor will root in a container starting in a wd subfolder of this "per-task" folder, will create such a directory in the batch task's working directory, and will set such directory as the root of the executor's filesystem view.
4. On failure, this same folder is the new destination of the stdout.txt and stderr.txt files, as well as the metrics.txt file.
5. There is no "public" configuration around this new container. It is NOT a replacement for cromwell-executions.
6. Trigger Service is altered to look in this new location to generate the per-workflow metrics files that are placed in the Outputs container.