refactor `create_from_fastq` / `fromfq` to leverage kallisto max memory options

[jfx319]

perhaps a refactoring of the fromfq and create_from_fastq is overdue given the updates to kallisto, bustools, and kb wrapper.

• emprically, I am observing much greater memory usage from the loompy process (loompy steps after kallisto finishes); e.g. kallisto uses ~17GB when invoked from loompy, while subsequent loompy steps after the kallisto pseudo align starts piling up memory, and rises to upwards of 140GB (Removing redundant reads using UMIs step), which can easily trigger oom job failures that the user can't do much to control
• the newest kallisto parameters allow setting a max-memory which could be passed from loompy
  • there is no way to control memory usage right now from the loompy invocation
• the newest kallisto workflows run exceedingly fast (almost twice as fast as loompy's invocation if kb is invoked directly in my 16threads comparison)
• the more involved parsing by loompy's create_from_fastq is now served by some similar-looking functionality taken care of by the kb wrapper, all without needing to take more than 30GB RAM (makes use of tmp disk space)
• in general, it seems to me a major benefit of the kallisto ecosystem is the low-RAM assurance combined with fast run time, so some way of ensuring RAM is user-adjustable would be nice to have for various hardware configs so jobs don't fail unexpectedly
  • therefore, it would be nice to refactor loompy's wrapper to set some better defaults that take advantage of these performance benefits
  • there is also a --tmp flag that can help with #119

As the kb ecosystem gets better, it will probably be easier to just leverage their maintained --workflow since their goals are aligned with improving performance. However, the additional perspective from the loompy parsing demonstrates other useful metadata that could be parsed out, and demonstrates how to store it into the loompy object, which the kb tutorials don't always pay as close attention to.

[jfx319]

loompy fromfq wrapper versus kb count wrapper (on the same dataset, same ref index files, same hardware, same kallisto & bustools binary versions). It didn't seem like kallisto was able to leverage the extra cpu's, so for the kb count run, I reduced it to 8 threads, and since kallisto doesn't use that much memory, I also added a max mem parameter of 20g (was run on the same node though).