Updated motif processing to Tangermeme 0.4

[avantikalal]

Replaced pymemesuite with tangermeme for all motif handling.

Specifically

1. Removing pymemesuite:

• removed pymemesuite dependency from setup.cfg
• removed pymemesuite from the dockerfile

2. Reading motifs into a dictionary format instead of pymemesuite format

• changed read_meme_file so that it now reads motifs in the dictionary format that tangermeme expects
• updated the test for the above function
• Removed modisco_to_meme since it is no longer necessary to have a meme file input. Instead, added a read_modisco_report function that reads modisco motifs directly into the dictionary format that tangermeme expects
• added tests for the above function
• renamed grelu.io.meme to grelu.io.motifs as this module now involves modisco .h5 files in addition to meme files

3. Changing downstream functions

• changed motifs_to_strings to use the dictionary format as input
• changed scan_sequences to use tangermeme fimo function as backend
• improved the test for scan_sequences
• changed the grelu.transforms.seq_transforms.MotifScore class to use the dictionary format as input

4. Misc

• also removed the padding argument from grelu.interpret.motifs.trim_pwm since we no longer have a use case for it

[avantikalal]

Partially addresses #55

[suragnair]

I think the trim should be done on the pwm and not cwm? cwm values are not normalized in any way generally

[avantikalal]

I based this on the modiscolite repo where trimming seems to be done on the CWM, e.g.:
https://github.com/jmschrei/tfmodisco-lite/blob/main/modiscolite/report.py#L98
https://github.com/jmschrei/tfmodisco-lite/blob/main/modiscolite/report.py#L236

Is it incorrect?

[suragnair]

Ok I had a look. Trimming on CWM is fine.

So it looks like within trim_pwm, the function recomputes the threshold as
trim_thresh = np.max(score) * trim_threshold
This is a bit unexpected to me, as the threshold should be used as is. Originally, I imagine it's for PWMs where the range is fixed (probs from 0 to 1).

My suggestion would be to compute exact threshold outside function call

[avantikalal]

Actually, I think the threshold is meant to be calculated on the log-odds matrix, not on the probability matrix. Let me find a reference for that.

[avantikalal]

Here you go: https://bioconductor.org/packages/devel/bioc/vignettes/universalmotif/inst/doc/IntroductionToSequenceMotifs.pdf

Specifically, this section on page 4:

While the context here is motif scanning, not trimming, this is the threshold that we're calculating. It's related to entropy of each position.

[suragnair]

I see. In either case, the exact threshold calculation should happen outside the trim_pwm function. Trim should just take a matrix, some threshold and perform the trimming using that threshold