feat: execute tests

[a-frantz]

Describe the problem or feature in addition to a link to the issues.

Execute the test definitions defined by #468 🚂

relevant links:

• rfc: sprocket test rfcs#1
• ci: drop pytest in favor of Sprocket test stjudecloud/workflows#263
• feat: document dev test sprocket.bio#22

Before submitting this PR, please make sure:

For external contributors:

• You have read the contributing guide in its entirety.
• You have not used AI on any parts of this pull request.

For all contributors:

• 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 added an entry in the CHANGELOG (when appropriate).
• You have updated the README or other documentation to account for these changes (when appropriate).
• You have either (a) made a PR to the next branch in the sprocket.bio repository [if you are a Sprocket team member] or (b) have suggested any changes you think need to be made to sprocket.bio in the description of your PR [if you are an external contributor].

For PRs containing lint rule changes:

• You have updated any and all effected entries within RULES.md.
• You have added a test case in crates/wdl-lint/tests/lints that covers every
  possible diagnostic emitted for the rule within the file where the rule
  is implemented.

[a-frantz]

copying a comment I made on Slack that explains some of the vision implemented in this PR:

doc sets a precedent for a "WDL workspace" concept that is being extended with test. A WDL workspace is not all that different from a git repo and it should be intuitive (I would expect just about every workspace to also be a git repo, although we aren't interacting with git at all). The basic assumption is that there is a "root" of the workspace which is just a local-on-disk directory with arbitrarily nested WDL documents within it.

Relative to this "root" of the workspace is expected to be a test/ directory. Under test/, there will be fixtures/. Test definitions are always loaded with <workspace>/test/fixtures/ loaded as the "origin". So to reference test/fixtures/test.bam in a test, the test definition would simply reference test.bam without any pathing. If users want to set up nesting or structure for their fixtures, that is also possible. Imagine a test/fixtures/bams/test.bam file exists, that would be referenced in test definitions as bams/test.bam.

Tests are also run inside the test directory, specifically at test/runs/<entrypoint>/<test name>/. The <entrypoint>/<test name> directory gets blown away on re-runs of sprocket test (I don't see a rationale for persisting test executions. That just sounds like disk bloat to me).

The "custom" test executables are at test/bin/. PATH=<workspace>/test/bin/:$PATH will be added to the child process so that any custom executables (bash/python scripts for example) are easy to reference.

This PR does not reference or interact with the test/bin/ directory. That's coming in a future PR.

[peterhuene]

Looks great! Just a few minor comments.

[peterhuene]

Just a few minor comments.