Loopplugin touching windows + plugin documentation

[JoranAngevaare]

What is the problem / what does the code in this PR do
As explained in #221, having a touching windows option might be nice to add in the LoopPlugins. This PR adds that.

Experimental
Note: as Daniel correctly pointed out (#424 (review)), this may lead to ambiguity if for example one peak is touching the window of two events, this would mean that if one is looping over events, that one peak is included twice. Depending on the application, this may or may not be an issue.

For now, we added a warning to alert the user of this (potential) issue.

Can you briefly describe how it works?
It's only a time-selection that allows to slightly extend the time range.

Can you give a minimal working example (or illustrate with a figure)?
Please see the tests for an example.

Documentation
Has been updated, additionally, I wrote out some examples that might be useful and work without any straxen installation.

[WenzDaniel]

Ah here we have to be careful. At least we should discuss it. For touching windows you can become ambiguities and use the same data twice which is not desirable. E.g. if you have a peak which touches two adjacent events it will be associated with both. See as an example: https://github.com/XENONnT/straxen/blob/a49c51ac1fda5be8e35f1ff19b4637d7a89700da/straxen/plugins/veto_events.py#L173-L181 in which I had to deal with such cases.

While I think such a plugin could be in principle useful, I am not sure if it will be easy to find a general rule about how to solve these ambiguites.

[JoranAngevaare]

@WenzDaniel , thanks, valid point. While I agree that this a potential issue, it is not per se a bad thing, people should be careful with what they do with that data indeed. If you want to have e.g. a more meta-number like how many peaks are at least partially overlapping with an event, having peaks taken into account twice might not be a huge problem.

I don't have some concrete examples where this would be used, I think there is no a-priori problem if we allow this to be supported.

How about the following:

• I add a comment in the plugin;
• I for now raise a warning in the plugin when this option is ever used (it can be disabled then if needed)

[WenzDaniel]

Yes, I agree we should add both a comment and a warning.

[JoranAngevaare]

@WenzDaniel , thanks again done, also added a reference to this PR as well as updated the description of this PR.

[WenzDaniel]

Thanks

[JoranAngevaare]

@WenzDaniel thanks for the review and the good comment 😄