fix: XString comparison operators

[ahl27]

Adapted from Bioconductor/XVector#6

Scope of this fix has been narrowed to just operating on XString objects (and their comparison(s) with character) rather than all of XVector.

The buggy behavior previously mentioned in the Biostrings TODO has been fixed to the following behavior:

> DNAString("A") != "A"
[1] FALSE
> DNAString("A") <= "A"
[1] TRUE
> DNAString("A") >= "A"
[1] TRUE
> DNAString("A") < "A"
[1] FALSE
> DNAString("A") > "A"
[1] FALSE
> DNAString("AAA") == "AAA"
[1] TRUE
> DNAString("AAA") <= "AAA"
[1] TRUE
> BString("AAA") <= "AAA"
[1] TRUE
> DNAString("A") > DNAString("A")
[1] FALSE
> DNAString("C") > DNA_ALPHABET
 [1]  TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE
[13] FALSE  TRUE FALSE  TRUE  TRUE  TRUE

Note that there's a bit of a decision to be made with something like RNAString("U") < "T" and RNAString("U") == "T". I chose to coerce to BString to use existing previously written methods, since it has consistency with prior work and consistency across inequality and equality comparisons. You could make the argument that RNAString("U") == "T" if we're always interpreting letters as bases, but then we get into tricky territory with the inequality operators (i.e., who is to say if DNAString("A") < DNAString("C")? Do bases have an inherent ordering?). This solution seems to be the most internally consistent and closest to the behavior I'd expect as a user. It also results in the fewest confusing error messages (handling cases like DNAString("C") < "E" is more challenging).

Unit tests have been updated. They're a bit verbose so that we could cover a lot of the possible input variable arrangements.

[ahl27]

workflow runs are broken until new bioc release, I can't get it to pull in Seqinfo correctly.