Thermo Stellar SRM spectra improvements

[chambm]

• changed Thermo processing of SRM spectra to only create chromatograms for them if the scan range is less than 1 m/z
• fixed spiky chromatograms in Skyline when processing SRM spectra (Skyline had not been checking whether the target Q3 m/z was within the scan window)

• fixed HasSrmSpectraInList to check fileDescription for "SRM spectrum" term
• added MS_raw_ion_mobility_drift_time_array variant for reading combined ion mobility spectra

@nickshulman @brendanx67 if you could review the Skyline changes I'd appreciate it. I originally made the filter step in FilterQ3SpectrumList, but that required allocating new lists and Brendan suggested that might be a performance issue. So I moved it into the spectrum processing loop. It has to check the ReferenceEquals(Ms2ProductIons,) bit so it only applies to calls from FilterQ3SpectrumList.

[nickshulman]

I think it would be better if the code which decides to filter out spectra based on scan window were moved into "FilterQ3SpectrumList".

For SIM spectra, that filtering happens in "SpectrumFilter.SrmSpectraFromMs1Scan".

I think it makes sense for the new code in this PR to happen in FilterQ3SpectrumList.
I would not worry about the performance implications of copying the MsDataSpectrum array.

[chambm]

I think it would be better if the code which decides to filter out spectra based on scan window were moved into "FilterQ3SpectrumList".

For SIM spectra, that filtering happens in "SpectrumFilter.SrmSpectraFromMs1Scan".

I think it makes sense for the new code in this PR to happen in FilterQ3SpectrumList. I would not worry about the performance implications of copying the MsDataSpectrum array.

I benchmarked WatersVsMz5OptimzeCeImportPerformanceTest with the filtering code in FilterQ3SpectrumList vs. in FilterSpectrumList and there was no discernable difference.