feat: implement workflow evaluation.

[peterhuene]

This PR implements workflow evaluation in wdl-engine and in the wdl run command.

Workflow evaluation works by taking the workflow evaluation graph and "splitting" the graph into subgraphs at each entry into a conditional and scatter statement.

For conditional statements, their subgraphs are only evaluated if the conditional expression evaluates to true.

For scatter statements, their subgraphs are evaluated for each element in the scatter array.

Workflow evaluation is currently single-threaded. Progress is made on the evaluation graph as much as possible until no more progress can be made, at which point evaluation will wait for outstanding tasks to complete.

Currently local task execution is limited to the amount of available parallelism supported on the host system; in the future, we'll want that to be configurable.

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.

[peterhuene]

The test error is:

error: call to function `read_int` failed: file `calls/count_lines/stdout` does not contain an integer value on a single line
   ┌─ tests/workflows/task-outputs/source.wdl:27:22
   │
27 │     Int line_count = read_int(stdout())
   │                      ^^^^^^^^

Looking into it (probably yet another line ending difference issue).

[peterhuene]

Not a bug; the WDL test source isn't quoting the path in the task's command, causing the backslashes in the path on Windows to be interpreted as escape sequences.

The task was failing in a piped command (also wasn't setting pipefail), which is why the task succeeded, but the read_int call failed since the output file was empty.

I'll push up a fix momentarily.

[claymcleod]

💯

[a-frantz]

I'd expect this to fail at runtime, but because the failure is nested inside a placeholder it instead just creates an empty string? That's an interesting side effect that could lead to hard to find bugs.

[peterhuene]

That's right, if a failure occurs due to an evaluation of a None, the placeholder doesn't fail but evaluates to empty.

If an expression within a placeholder evaluates to None, and either causes the entire placeholder to evaluate to None or causes an error, then the placeholder is replaced by the empty string.

[a-frantz]

I was aware of the of the first part but not the error clause. That seems problematic to me.