Split tasks to a new repository

[adthrasher]

Finally, we plan to migrate the WDL tools to a new repository. There are several tasks required before we can make the change.

• [ ] Review open PRs on workflows
• [ ] Update documentation (apparently we have a docs/build_for_dnanexus.md that's wildly out of date)
• [ ] Check CI/CD workflows for any needed changes
• [ ] Draft tools-specific README
• [ ] Draft tools-specific contributing guide
• [ ] Update workflows README
• [ ] Choose repository name
• [ ] Choose versioning scheme
• [ ] Move cellranger tasks/workflows to a private repo
• [x] Bring all tools+dependencies up to date

[a-frantz]

Choose versioning scheme

My proposal, as loosely inspired by how I've seen many Rust crates organized (like noodles):

• Repo version + tool versions
  1. Version each file (tool) individually (DO NOT make GitHub releases for each of these updates)
     • scheme: same as our docker tagging system. i.e. we track both the "base tool version" (like STAR v2.7.11b) AND we append our own revision number to it (like -0 or -1). Final product: v2.7.11b-1
  2. Make repo-wide tagged releases ad hoc
     • We start with v1.0.0 to indicate we're "production ready" and most of our updates will either be a "patch" or "bug fix" release that increments the patch num, OR a minor release. I think "breaking changes" would only be defined by some major architectural change and I can't think of an example. But they'd be very rare.

How a user interacts with this: If they are only using a single tool, they could import that specific file, with that \-\ tag. This is kind of a "mouthful" of a version. I view this as being for advanced users. If they are using a whole bunch of different tools/files, they would specify a "repo version" which would obfuscate the file-level versions.

How we interact with this: Since we won't be pinging users for every tool revision, we can feel free to update these as often and as trivially as we want. We only ping users when we've made enough changes that we want to notify them. And then we make a repo-wide release.

If a user wants to be on the bleeding edge, they can import everything at the latest file/tool level. However we would recommend most users to use the "convenience" version that packages everything together as a v1.x.x.