Match CPUs/memory task requests to cli arguments

[k-florek]

After a discussion it seems like the best way forward may be to match the task request to the cli argument since this would utilize cloud resources most effectively. It could cause issues if the workflow is run on local environments but those issues will have to be addressed as they arise, potentially with an additional configuration file.

From @jvhagey review: Ex: for Seqyclean - runtime is requesting 2 CPUs and -t (threads) is defaulted at 16. "cpus" argument should be changed to "threads" where appropriate to be clear where it is threads and where it is CPUs.

[jvhagey]

For each task that has CPUs as an input:

• [x] Check if the program run in the command{} block has an argument for CPUs or threads.
• [x] If argument is for CPUs then the CPU input variable should be passed to the command{} ~{cpus} variable and to a runtime{} as a variable ~{cpu}. Currently, most of the tasks have an integer as in the runtime argument for cpus rather than a variable being passed. In other words, the runtime{} cpu argument should match what is requested in the input{} and passed to command{} ~{cpus} variable.
• [x] If the program has an argument for threads than a line should be added within the command{} block to create a new variable ~{threads} that is 2X the requested ~{cpu} in the input{} and pass this new ~{threads} variable to the program rather than ~{cpu} . As with the point above add ~{cpu} to the runtime{} cpu argument to make sure what is requested in the input{} is passed to the runtime{} cpu argument.

Comment when a task has been checked and edited.

[k-florek]

I believe I have addressed all of these points with Pull Request #12 please let me know if I have missed anything.