refactor: change workflow evaluation to use tokio::spawn.

[peterhuene]

This refactoring primarily affects wdl-engine and how workflows are evaluated. Previously, workflows were evaluated without spawning any tokio tasks. This meant that subgraph evaluation was not concurrent, although WDL tasks were spawned concurrently.

With the upcoming support for integrating Crankshaft, the Backend trait was refactored such that the backend itself can maintain state and notify callers of when a WDL task is spawned and when it completes. This allows for the local execution backend to be rewritten in a way that enables it to respect the cpu and memory requirements of a WDL task.

To support making the evaluator futures Send, we now utilize rowan::AstPtr to send AST nodes between threads performing evaluation. The evaluation graphs are mapped to be Send so that evaluation can keep a shared reference to the graph across concurrently executing tokio tasks.

Also included with these changes:

• Use tracing-indicatif to prevent mixing of tracing output and progress bars; the progress bar now consistently shows at the end of tracing output and can also be quieted.
• Made wdl_analysis::Document trivially clonable.
• Minor changes to internal names in wdl-analysis.
• Fixed a missing constraint on the basename function definition for an overload that's only required for WDL 1.2.
• Added a Config type to wdl-engine that controls how evaluation is performed; in the future this can be used to support evaluation configuration files.
• Expanded the ProgressKind enumeration to allow for tracking how many tasks are "ready" (i.e. waiting to be spawned by the backend) vs. "executing" (i.e. currently running).
• Removed the incorrect mapping of host paths to guest paths; this will soon be reimplemented as part of the initial support for a Docker backend.
• Added retry logic to task execution.

Before submitting this PR, please make sure:

• You have added a few sentences describing the PR here.
• You have added yourself or the appropriate individual as the assignee.
• You have added at least one relevant code reviewer to the PR.
• Your code builds clean without any errors or warnings.
• You have added tests (when appropriate).
• You have updated the README or other documentation to account for these
  changes (when appropriate).
• You have added an entry to the relevant CHANGELOG.md (see
  "keep a changelog" for more information).
• Your commit messages follow the conventional commit style.

[a-frantz]

Q: what about the temp dir on retries? And stderr/stdout files? Are those overwritten or preserved?

[peterhuene]

Looks like a new nightly was released that changed formatting, so need to bump my local nightly and reformat.

[peterhuene]

Q: what about the temp dir on retries? And stderr/stdout files? Are those overwritten or preserved?

There are now two temp directories in the directory layout as described in a previous comment: one is where files are created before and after we evaluate the command and one is for the evaluation of the current attempt's command.

So effectively they are preserved from attempt to attempt along with the command/stdout/stderr files.