Refactoring the Queue to allow for improved playing options

[ThomasFrans]

Is your feature request related to a problem? Please describe. Currently the Queue works as a normal, simple Queue. This version allows for basic control of the playback order of songs, like add to queue, play next, and play now. My request would be to improve the structure of the current Queue to allow for more fine grained control.

The current options would still work the same way as before. All the new stuff would be optional. There could be a configuration option to enable or disable the more advanced options for users who want to use a simple queue, and not have all the extra options in the context menu.

The new queue would allow users to:

• Play a different song right now; "I just want to listen to this song without affecting the rest of the queue"

• Play a different song and change the spare songs; "I want to listen to this song, and change the spare songs"

• Play songs after this one, but before the rest of the queue; "After the current song, I want to listen to these songs first, and then the rest of the queue"

• Build a queue; "I would like to listen to this stuff"

• Shuffle the queue, but not the short-term next songs;

• Add something to the beginning of the queue.

Describe the solution you'd like I'd like the queue to be split into 4 parts:

1. Current song: The currently playing song.
2. Next songs: Songs the user wants to play after the current song, but before the rest of the queue.
3. Queue: The standard queue. It contains songs the user deliberately put there.
4. Rest/Spare songs: A queue of spare songs, for when there are no more songs in the previous queues. This queue is only changed when the user directly plays a song or container (album, artist, playlist, show). The idea is that the user would probably want to hear the songs they deliberately put in their queue first, before the stuff that was added automatically. There could be a configuration option to add full containers (or some containers like albums and playlists) to the queue directly as the user may always want to listen to all songs in them.

The solution could be implemented in steps to limit the refactoring work to get working versions:

1. Refactor the Queue but keep the API the same (use the new structure with the same API);
2. Rename the current functions to make their purpose more clear and document them;
3. Refactor the API (adding new functions and also documenting them, and adding them in the UI for the user to use).

Describe alternatives you've considered Not really an alternative but I forgot to look in the closed issues. I found issue #69 which tried something similar in the past. If I were to try and implement this, I'd probably start from scratch instead of working on the previous pull request as it's 2 years old already...

Additional context Currently, I just see this as a suggestion for further brainstorming. This issue isn't a 100% complete description of the solution, because I wanted to ask first if this was even a wanted improvement. The idea would probably require some refactoring, not only to the queue but also to the ListView items (currently for example, there is no clean way for contextmenus to show options for shows and genres. Also there should be a way for items to be put into the queue as a single item so the ListView can show the playback status of items). I wanted to ask for an opinion about this basic idea before maybe working on an initial implementation.

[MNolan147]

I'm also have some problems with the current queue system and this seems like it would be a better system.