fixes peak boundaries in PeakPickerHiRes (resolves #1022)

The previous version of the PeakPickerHiRes algorithm relied on trailing zeros of peaks to detect peak boundaries correctly. If such zeros are not present, as in simulated data, the peak boundaries were extended to the previous and next peak, see #1022. This pull request resolves to issue by checking for large gaps in m/z.

The following changes were made:
(i) The number of allowed missing data points when extending to the left/right is now  variable. It can be set with the new advanced parameter missing_.
(ii) Locally, the spacing of the m/z is constant. A missing data point can therefore be defined by > 1.5 * min_spacing [1]. This magic number does not even appear as advanced parameter.
(iii) A large gap is now defined as > spacing_difference_ * min_spacing with default spacing_difference_ = 4. If such a gap occurs the extension is stopped.

The modified code is not used on typical orbitrap data (trailing zeros before big gaps, no missing data points). In simulated data the peak boundaries are now correctly detected, see extended PeakPickerHiRes_test. Together with @timosachsenberg we compared before/after on an orbitrap and a simulated data set.

[1] min_spacing is the smaller of the two m/z steps to the left/right from the seed.
@hroest I had a quick discussion with @timosachsenberg yesterday. We wanted to put this up for discussion in the pull request. Here is my reasoning (but I am also happy to introduce a new parameter):

The concept of a 'missing data point' makes only sense in (locally) equispaced data. If they aren't, you couldn't spot one missing. If they are equispaced, the m/z steps vary only minutely. With any factor 1.1 < f < 2 you can spot that a data point from a series was removed. The fewer (advanced) parameters the better.