Add in sORF prediction to peptigate using plmutils

[taylorreiter]

PR checklist

• Tag the issue(s) or milestones this PR fixes (e.g. Fixes #123, Resolves #456).
• Describe the changes you've made.
• Describe any tests you have conducted to confirm that your changes behave as expected.
• If you've added new software dependencies, make sure that those dependencies are included in the appropriate conda environments.
• If you've added new functionality, make sure that the documentation is updated accordingly.
• If you encountered bugs or features that you won't address, but should be addressed eventually, create new issues for them.

PR Description

This PR adds in sORF peptide prediction based on plmutils. A lot of the code I had in place for sORF prediction was changed or deleted now that we aren't using RNAsamba. I didn't have to add any new environments, as everything was already present from the curation/model snakefile and the existing workflow.

I decided to add the plmutils model as a config path. @keithchev, I would appreciate input as to the best way to provide the models, info for the two files is below:

$ ls -lah inputs/models/plmutils/
total 36M
drwxrwxr-x 2 ubuntu ubuntu 4.0K Mar 12 20:21 .
drwxrwxr-x 6 ubuntu ubuntu 4.0K Mar 12 20:20 ..
-rw-rw-r-- 1 ubuntu ubuntu  36M Mar 12 20:21 classifier.joblib
-rw-rw-r-- 1 ubuntu ubuntu  41K Mar 12 20:21 pca.joblib

I think I'd like to provide them in the repo (then the snakemake dry run in the github actions will also pass...), but I can switch things up to make them downloadable instead, or to provide them as a tar file and decompress them in the workflow. I didn't want to add them yet so as not to make the github history huge if we go the route of not putting them in the repo.

Documentation PR coming soon!

Testing

I confirmed that the new code runs on the test data set and outputs desired results.

[keithchev]

I think I'd like to provide them in the repo (then the snakemake dry run in the github actions will also pass...), but I can switch things up to make them downloadable instead, or to provide them as a tar file and decompress them in the workflow. I didn't want to add them yet so as not to make the github history huge if we go the route of not putting them in the repo.

Just to close the loop on this, we chatted offline and agreed to include the model files in the repo, as this is the simplest solution, it allows the dry-run action to pass, and the model files are not currently large or numerous enough to justify storing them elsewhere.

[keithchev]

Looks good! A few nits but nothing major. And it's totally fine by me to punt on my documentation-related comments to a future documentation PR.

[taylorreiter]

Merging now! there should be an additional chance for review/changes in a docs PR.