feat: Allow comparison of XVector objects (part 1 of 2)

[ahl27]

This is one of two PRs intended to fix a bug identified in Biostrings here: Bioconductor/Biostrings#51. Part 2 of the PR is located here: Bioconductor/XVector#6.

The bug identified was that comparing a DNAString with a single character caused a C stack too close to limit error. It turns out that the bug ran a lot deeper--comparison between XVector objects was completely broken. For example:

x <- XVector(10)
y <- sample(10)
x == y
## Error: C stack usage  7953792 is too close to the limit

XInteger(10) == XInteger(10)
## works fine

XInteger(10) < XInteger(10)
## Error: C stack usage  7953792 is too close to the limit

The culprit stems originally from the S4Vectors package. pcompare is defined for Vector objects, which uses order and sameAsPreviousROW to perform element-wise comparisons. However, neither of these methods are written for SharedVector objects, so they default to whatever we get from dispatch. order dispatches to the standard base::order function, which always causes a stack overflow when called on a SharedVector object. sameAsPreviousROW calls the default method in S4Vector, which calls .XVector.equals, which will always return c(FALSE, FALSE) or c(FALSE, TRUE) regardless of input size.

This PR adds in the functionality required in the S4Vectors package to support comparison between SharedVector objects. This is primarily just a C-level method to order an array -- this was previously in the package, but only supported integer vectors. This comparison uses memcmp when possible, but a separate method is included for numeric types because memcmp has weird behavior on doubles. Eventually will need to update the code to support the smart dispatch between sorting algorithms like in the other sorting functions, but for now this is sufficient.

[ahl27]

As with Bioconductor/XVector#4, I'll go through these methods to make sure there's consistency in their ordering -- based on a quick scan there are some that need to be moved around.