Check object is sorted before processing

[PeteHaitch]

It's clear from Lindsay's experience that we should probably check the BSseq object is sorted before smoothing (and likely before doing other operations too). I propose the following:

1. Request/contribute patch to add is.unsorted,RangedSummarizedExperiment-method to SummarizedExperiment - we then get it via inheritance for BSseq objects. Turns out there already an is.unsorted,RangedSummarizedExperiment-method
2. Add is.unsorted(BSseq) where necessary to bsseq codebase.
3. If the object is unsorted then eitehr sort the object (with message/warning) or simply throw an error.

One complication is that sort() for GRanges-based objects uses the seqlevel order from the Seqinfo slot - if this is "wrong" (as in Lindsay's case where chr3 was first) then the sort is "wrong". However, the relative order of positions within a seqlevel will still be correct, which I think is enough for what we want. In general, defining and checking a canonical order of seqlevels for an arbitrary sample with potentially limited metadata is very difficult, so I don't think we want to do anything in that space.

[PeteHaitch]

I took another look at the output of bismark_methylation_extractor. In general we can't assume anything about the genomic order of these output files. Processing paired-end data with bismark_methylation_extractor requires that the data are sorted by QNAME, which means that the output is ordered by the order in which it encounters different chromosomes.