Fix visual glitch when using next-terminates-loop

[melyso]

Fixes Issue

Closes #500

Description

The previous workaround to QMediaPlayer's limitations in changing looping behavior on-the-fly, involved stopping-and-resuming video clips mid-loop. This is replaced with setting an internal flag __termination_requested which indicates that termination has been requested. Furthermore, through implementing a slot for the positionChanged signal, the beginning of new loops are detected as non-monotonicity in the position (outside of the load_next_slide() function), which, after the __termination_requested-flag is set, triggers load_next_slide()function. This seems to remove any non-smooth behavior at the key press, and seems to advance the presentation to the next slide at the first possible finished loop iteration as expected.

Check List

Check all the applicable boxes:

• I understand that my contributions needs to pass the checks;
• If I created new functions / methods, I documented them and add type hints;
• If I modified already existing code, I updated the documentation accordingly;
• The title of my pull request is a short description of the requested changes.

Note to reviewers

It seems I got 3 warnings when running the tests locally, but they seemed to not be related to my changes. Due to only implementing the hook in question if the next-terminates-loop flag is set, my changes increased the complexity of the __init__ function from 12 to 13, although at 12 it was already above the threshold level (10) before my changes.

I am unsure if the adding of a slot to the positionChanged signal adds any significant overhead which could impact the performance/result in any increased lag in animations in general. I didn't see any clear signs of this when testing.

As this is simply a bug fix, nothing was changed in the docs.

[melyso]

I now realize I was mistaken in my note - the jump in complexity in the __init__ function seems to be from my changes. I tried to follow the structure of the existing hook setup in __init__, but ended up increasing the complexity by 3.

Would it be preferable to leave it as-is, should I deviate by defining the hook itself outside of init and only connect it within the conditional, or do you have another suggestion?