docs: add description of data reduction procedure

[jokasimr]

Fixes #7

This is still a bit coarse, but I think it contains the important bits.

~I'm marking this as a draft for now~

[jokasimr]

To avoid making this PR too large. I'll add separate issues for documenting:

• the frame unwrapping / how tof is computed
• coordinate transformations
• footprint correction procedure
• how the resolution function is estimated

[jl-wynen]

In general, splitting PRs into small units is good. But that only works when those units are self-contained. Here, I cannot judge whether the documentation is good without seeing all of it. In the last PR of this series, I would have to read everything again anyway. So can you please combine them into one PR?

[jokasimr]

The risk I see not splitting this effort into manageable pieces is that

1. It will never get finished, and never reviewed, because it will become to cumbersome. It's already quite a mouthful.
2. It will get out of sync with the code.
3. No one will have any use of it before everything is done.

I don't agree that the pieces are not self contained. You don't need to know the geometry of the beamline, the chopper setup etc, to follow what is done here. This part of the documentation assumes there exists some procedure to compute $\lambda, \theta$ etc but doesn't specify how that is done, and I think that is fine.

The same goes for the parts about footprint correction and the resolution function.

[jl-wynen]

If this was true, we would not need to do any error propagation at all before we compute a Q histogram.

Yes and we typically don't right?

But I see what you mean. There's something a bit wrong here. The events are weighted. So one > event is actually not a single events, but a "package" of events. Individual packages of events arrive independently, but inside a package the events don't arrive independently. I think we should talk about this in person to get the formulation right here. 👍

We should