Fix timing of peaks when ordering in center_time

[dachengx]

Before you submit this PR: make sure to put all operations-related information in a wiki-note, a PR should be about code and is publicly accessible

What does the code in this PR do / what does it improve?

strax.touching_windows requires that the time of things and containers are all sorted.

When the time and endtime are defined based on center_time in some plugins like PeakShadow and PeakAmbience, the touching_windows will show an error, because the center_time is not sorted.

Reference: AxFoundation/strax#725

Can you briefly describe how it works?

First, order the peaks by center_time, after the features are calculated, recover the original order.

Can you give a minimal working example (or illustrate with a figure)?

Please include the following if applicable:

• Update the docstring(s)
• Update the documentation
• Tests to check the (new) code is working as desired.
• Does it solve one of the open issues on github?

Notes on testing

• Until the automated tests pass, please mark the PR as a draft.
• On the XENONnT fork we test with database access, on private forks there is no database access for security considerations.

All italic comments can be removed from this template.

[coveralls]

coverage: 93.53% (-0.003%) from 93.533% when pulling b2f133a on fix_shadow_time_order into 8dc4417 on master.

[FaroutYLq]

Looks good to me. Just one quick sanity check: is it possible for two peaks to share same time? Seems no to me.

[FaroutYLq]

Will it be possible that a merged_s2s has same time as an S1 fully contained in it?

[dachengx]

Looks good to me. Just one quick sanity check: is it possible for two peaks to share same time? Seems no to me.

We have no functions to prevent that.

Similar case to center_time. But the mergesort algorithm of argsort make itself a stable sorting so that even though the center_time of two peaks can be the same, they will still be reordered correctly in the final result, because the argsort of two same center_time is still in the order of indices when sorting is stable.

[FaroutYLq]

Looks good to me. Just one quick sanity check: is it possible for two peaks to share same time? Seems no to me.

We have no functions to prevent that.

Similar case to center_time. But the mergesort algorithm of argsort is stable sorting so that even though the center_time of two peaks can be the same, they will still be reordered correctly in the final result, because the argsort of two same center_time is still in the order of indices when it is stable.

Then I have no concern. Please feel feee to merge it.