libertem_dectris: hard upper frame stack size limit in number of frames; optional latency limit

[sk1p]

When requesting a frame stack, the internal logic did not have a hard limit on the number of frames per frame stack - this was handled separately in higher level logic.

Now, if one has very small frames (let's say almost all zeros, detector running with beam blanked), the background thread would have a very high latency until it starts to yield data.

This PR changes the behavior to have control over the limits in the background thread:

• frame_stack_size is now also an upper limit of number of frames, in addition to estimating a slot size
• Add a new parameter, max_latency_per_stack, to have a built in upper latency limit per frame stack, which is needed for example for good interactivity with "long" frame times (1ms+) without having to set a large frame_stack_size (so one doesn't need to reallocate shared memory when changing frame_stack_size