extend sleuth to model TPMs

[warrenmcg]

Hi @pimentel,

This is the code to extend sleuth in prep for sleuth-ALR.

Here is a summary of the changes:

Transform both counts and TPMs independently

• split the transformation function into one for counts, and a separate one for TPMs. Default for counts is still log(x + 0.5); default for TPMs is identity (i.e. x --> x, or not transformed).

Process TPMs & counts similarly with process_bootstraps and sleuth_prep

• added code to process_bootstraps and sleuth_prep to process TPMs similar to how counts are processed (transform TPM values; create obs_tpm and sigma_q_sq_tpm)
• importantly, gene mode only processes counts when extra_bootstrap_summary is TRUE and only processes TPMs when read_bootstrap_tpm is TRUE (may speed up processing if someone is just interested in one or the other)

allow TPMs to modeled by sleuth_fit

• added which_var option to sleuth_fit to specify obs_counts (default) or obs_tpm; added to the print function for sleuth_fit objects to print which variable was modeled (counts or TPMs).

remaining to-dos:

• [x] extend sleuth_live to allow users to look at TPM or counts if both are modeled. DONE
• [x] right now, if users want to model both TPMs and counts on the same model, they have to be stored separately; I think this should remain the case, but wanted to check on this design decision. We decided users will be forced to model each separately.

[warrenmcg]

Hey @pimentel, so I think I've covered my bases with the two to-dos. I don't see other clear opportunities for users to need to know whether counts or TPMs are modeled within the sleuth_live environment. I think the print function for sleuth_model objects is sufficient for users to double-check which variable was modeled. Let me know what you think.