Improve handling of event data in NXdetector

[SimonHeybrock]

This resolves a number of inconsistencies and broken things. For example, slicing pixels works now. Behavior wise, we are now closer to the pre-v2 implementation.

When an NXdetector contains both dense data and events, this is not returning a Dataset. I don't know if this is useful in practice, or if we should just go back to returning the events by default?

[jl-wynen]

I don't know if this is useful in practice, or if we should just go back to returning the events by default?

Is the dense data typically used as a histogram of the events? If so, there should be an option to select which one to load. Or at least a postprocessing function.

[SimonHeybrock]

I don't know if this is useful in practice, or if we should just go back to returning the events by default?

Is the dense data typically used as a histogram of the events? If so, there should be an option to select which one to load. Or at least a postprocessing function.

I guess that the dense data is typically just meant as a "preview" of what you would get when histogramming the events. But good luck finding that documented anywhere. It is not even clear if having both is legal.

[jl-wynen]

I don't know if this is useful in practice, or if we should just go back to returning the events by default?

Is the dense data typically used as a histogram of the events? If so, there should be an option to select which one to load. Or at least a postprocessing function.

I guess that the dense data is typically just meant as a "preview" of what you would get when histogramming the events. But good luck finding that documented anywhere. It is not even clear if having both is legal.

Based on your answer, I suspect that it will be most useful to return the events as a data array and log that there was dense data that was not read. But this is just a hunch