Allow symlinks to inputs as WDL outputs

[adamnovak]

This makes Toil pass the test added in DataBiosphere/wdl-conformance-tests#38 and will fix #4850

I've also improved WDL error reporting (with emoji) and how early we detect non-nullable null outputs, since the problem was manifesting as a failing workflow output and not a failing task trying to output a symlink and was not pointing to the offending WDL line.

I've also added machinery to try and propagate through the original versions of files instead of re-uploading them, by remembering what we downloaded as what and consulting that when virtualizing and resolving symlinks.

Also, per openwdl/wdl#495 which says that WDL runners don't need to provide mutable inputs, I'm no longer making full files to mount into containers and I'm allowing the file store to hand us symlinks and to explicitly not give us writable files. This should increase how often we can mount workflow inputs straight into the container.

Changelog Entry

To be copied to the draft changelog by merger:

• WDL tasks can now output symlinks to their inputs.
• WDL tasks now accept symlinks from the file store.
• WDL tasks now remember downloads to avoid reuploads (and visa versa).

Reviewer Checklist

• Make sure it is coming from issues/XXXX-fix-the-thing in the Toil repo, or from an external repo.
  • If it is coming from an external repo, make sure to pull it in for CI with:

    contrib/admin/test-pr otheruser theirbranchname issues/XXXX-fix-the-thing
    

  • If there is no associated issue, create one.
• Read through the code changes. Make sure that it doesn't have:
  • Addition of trailing whitespace.
  • New variable or member names in camelCase that want to be in snake_case.
  • New functions without type hints.
  • New functions or classes without informative docstrings.
  • Changes to semantics not reflected in the relevant docstrings.
  • New or changed command line options for Toil workflows that are not reflected in docs/running/{cliOptions,cwl,wdl}.rst
  • New features without tests.
• Comment on the lines of code where problems exist with a review comment. You can shift-click the line numbers in the diff to select multiple lines.
• Finish the review with an overall description of your opinion.

Merger Checklist

• Make sure the PR passes tests.
• Make sure the PR has been reviewed since its last modification. If not, review it.
• Merge with the Github "Squash and merge" feature.
  • If there are multiple authors' commits, add Co-authored-by to give credit to all contributing authors.
• Copy its recommended changelog entry to the Draft Changelog.
• Append the issue number in parentheses to the changelog entry.

[DailyDreaming]

I think that this looks alright.