Decouple DRAM v2 tool code from Nextflow code

[madeline-scyphers]

In the development of DRAM v2, DRAM code was coupled with Nextflow, meaning that to run DRAM, you can only run it from NF. It would be more ideal if DRAM was decoupled from Nextflow so that you can run DRAM with or without NF. This offers several advantages:

• Users have more options - They can install it with NF, which has a lot of deployment advantages. Making it super easy to run DRAM on an HPC, in a cloud deployment (AWS, Azure, etc.) or locally. But potentially users can't install NF (or don't want to for whatever reason. Allowing direct installation gives more options.
• Development - A lot of the testing with DRAM v2 has to be done by running it through Nextflow, which complicates testing options. Making it harder to test. It also makes it harder to debug. It would be much easier to debug if you could run DRAM v2 directly. Use a lot of language-specific debugging tools, and then have NF wrap around that.
• Containerization could be done automatically for us if we move in this direction. Various tools exist that convert conda packages to containers with next to 0 effort (with hosting). bioconda packages (conda packages on the bioconda channel) automatically get converted and hosted as biocontainers. Any conda channel package can be made and hosted as a seqera container the same way if requested. And then it is as simple as a couple lines in the NF configuration file to have the containers pulled automatically for users.
• If DRAM is decoupled from NF, there is the possibility if desired to develop as hook or callback system to let users build customizations for DRAM to run their own processing steps or something like that at predefined places. This could be done without decoupling, but decoupling makes it easier.