feat: loop playlist when last element is done playing

[JustSomeDevPerson]

Description

Adds checkbox to the queue and starts the playlist again after its done playing

Related Issue

This would close #2913

Testing

I manually tested the behavior with and without the flag set to true

Screenshots

Interface Settings before the change:

Interface Settings after the change:

Queue Settings before the change:

Queue Settings after the change:

Checklist

• I have read and understood the Contributing document.
• I have read and understood the AI Usage Policy document.
• [] I have made corresponding changes to the documentation (if applicable).
  • I'm not sure if there is corresponding documentation. I modelled the setting after the "continue" setting, so I added code and text for the setting everywhere I found the continue setting as well, to make sure I didn't miss anything. If I still missed a spot, just let me know and I'll fix that.

AI Usage Disclosure

• I have used AI tools to assist with this pull request, and I have disclosed the tools and how I used them below.

I used copilot to figure out what needs to be added and where, then I added the code in the same schema that the "continue" setting uses.

I also used copilot to quickly skim if I needed to set up docker to test my changes or if I could do it without.

The code itself and the text for english and german are from me, but as I stated, I oriented myself on the "continue" setting, to keep things consistent.

Additional Context

I didn't add any other translations than english and german, because thats the only languages I speak. I can try to create translations for other languages using AI if necessary, but I'd rather avoid that unless its needed.

[DogmaDragon]

Disclaimer: Not developer.

There is another PR #5012 targeting the same issue.

I prefer the UI of that one and but I also like the default setting from this one.

[JustSomeDevPerson]

There is another PR #5012 targeting the same issue.

I prefer the UI of that one and but I also like the default setting from this one.

The problem is, the other PR is already two years old with 0 interaction on it, so I think not changing UI more than necessary and having the feature implemented in a similar fashion to an existing feature thats somewhat similar in nature might has better chances on being approved.

I do agree that the UI in the other PR is better, but improving the UI can be done in a second step as well.

[Gykes]

I would say for a feature like this it should be done in one PR. You can cherry pick it over from the other PR or just copy. The old PR probably has too many merge conflicts to be viable.

[JustSomeDevPerson]

I would say for a feature like this it should be done in one PR. You can cherry pick it over from the other PR or just copy. The old PR probably has too many merge conflicts to be viable.

If the decision is to incorporate the UI changes from the other PR as well, then doing it in one PR is probably preferrable. I'm just not sure if that decision is already made and if there's consensus about the look of the additional UI elements.

So for now I'm going to stick with this version and if it gets decided that the UI should be changed as well, I'll cherry pick the corresponding changes.

I just want to prevent starting a big discussion on UI elements.