Add tests for some ion mobility files

[sneumann]

Hi,
we should test the reading and peak picking functions some time in the future how well it handles peculiarities in IMS data.
An addendum to the mzML spec says:

There was some concern that in the original mzML 1.1 format there should never be two 
identical m/z values in an “m/z array”. But this was not explicitly stipulated in the mzML 1.1 
specification, and with the addition of ion mobility arrays, repetition in the “m/z array” will be 
common (having differing ion mobility array values). This means that all mzML parsers SHOULD 
be checked/updated to handle mzML data with non-increasing (identical or decreasing) m/z values 
in the "m/z array". All parsers SHOULD also be updated to warn or halt gracefully if they are not prepared 
to handle the kinds of data described herein.

This has time until a suitable collection of example mzMLs are available,
but I wanted to note this somewhere for reference.
Yours, Steffen

[jorainer]

Good point. In some functions in Spectra (and for some backends) we check if or ensure that m/z values are ordered. AFAIK all our functionality should be safe even if m/z values are not ordered. The only functions where it is critical are the m/z comparison, grouping and binning functions in MsCoreUtils. But these by default check for ordered m/z values.

xcms uses now also Spectra et al - so it should suffice if we fix it there.