Include non-zero transition-time from open<->closed in `tof.chopper_cascade`

[SimonHeybrock]

This is due to a non-zero guide side. See https://pubs.aip.org/aip/rsi/article/85/11/115103/356359/Choppers-to-optimise-the-repetition-rate (https://backend.orbit.dtu.dk/ws/portalfiles/portal/102784335/1.4900958.pdf) Fig. 3 and, e.g., Eq. (6) and (7).

In practice we might also need an option to define a cutoff, e.g., to ignore the tails below a threshold.

[SimonHeybrock]

@nvaytet Should this be moved to essreduce?

[nvaytet]

We left the chopper_cascade module in scippneutron, so I would say no, it should stay here?
If you want to make more accurate chopper acceptance diagrams, it should still be added here.

In essreduce, we will either use tof or McStas to compute time-of-flight.
McStas already does this. I guess it should be possible to add to tof relatively easily? (have some sort of transmission function convoluted to the opening of each chopper? although currently neutrons either go through or not, so choppers would now have a non-boolean opening, so it might be a larger change...)

[nvaytet]

Because of the move towards using tof and McStas to compute time-of-flight, this has moved down the priority list.
I'm removing this from triage for now.

[SimonHeybrock]

Question is, should it be reformulated to "Include non-zero transition-time from open<->closed in tof simulation"? Isn't this effect still equally relevant? Or are you counting on using McStas in production so this is addressed automatically?

[nvaytet]

I was going to rely on mcstas, but we can also transfer this issue to tof, so that it cna also handle this case?