Important bug fix for ambigous character resolutions

[spond]

Thanks for Reagan Kelly of the CDC for tracking down this issue.
Starting in version 1.0.8 there was a subtle bug that would manifest if the first ambiguous character in the first sequence being compared fell on an odd (0-based position) in the first half (roughly) of the sequence. This would cause the code to incorrectly skip the pair of nucleotides with the ambiguous base and instead double-count the next pair of characters, so in something like

ambig-bug.fas
....

>Seq1
AAAARCTTTTTTT
>Seq2
AAAAACTTTTTTT

So for example

tn93 -l 5 -q -a average ambig-bug.fas

would return 0 for the distance between Seq1 and Seq2, because instead of comparing the R-A pair, the code would instead compare C-C (the next position)