fix: allow for IUPAC codes in GetCanonicalMotif()

[aryarm]

partially addresses #238

This will allow TRTools's GetCanonicalMotif() to work for sequences that have IUPAC codes. However, this will not entirely solve the problem described in #238, since any function that calls GetCanonicalMotif() will now have to handle the IUPAC codes somehow.

[LiterallyUniqueLogin]

Aside from the reverse complement issue, whether or not this should be done depends on how it is used or intended to be used. I see no uses of GetCanonicalMotif or ReverseComplement in TRTools, so I cannot evaluate that and instead leave that choice to you.

[aryarm]

Thanks for the suggestions! I tried my best to implement them in c1f78ee. Does that look better?

I see no uses of GetCanonicalMotif or ReverseComplement in TRTools, so I cannot evaluate that and instead leave that choice to you.

In this case, I think GetCanonicalMotif() is being used to discover whether variant records from different callers are mergeable in EnsembleTR:
https://github.com/gymrek-lab/EnsembleTR/blob/43104bfac4f98e5ea7500e2220500c21e6f337c5/ensembletr/vcfio.py#L230
(There might also be other uses, but from what I can gather, that's the main one.)
So once this PR is merged, it would behoove us to handle IUPAC codes in EnsembleTR, as well. We will have to ensure that AGRG is marked equivalent to AGAG, for example.

[LiterallyUniqueLogin]

This looks good!

(Though I haven't personally checked your complement table is fully correct :) )

[aryarm]

great, thanks for the review, Jonathan!

[aryarm]

It turns out that this PR actually isn't helpful for fixing the issue in EnsembleTR anyway, so I'm just going to close it for now.

Feel free to reopen if it's ever needed!

In the meantime, you can follow gymrek-lab/EnsembleTR#32 for the next chapter of this story