Allow editing of saved queues

[TCHalogen]

Overview
Queues that are created and saved have no capability of being edited within the game's interface. The only way to do so is through the undocumented method of copying the queue, which sends a JSON object of song IDs and a name to the clipboard, and pasting it to a notepad — leaving users with information that may be too technical to understand.

Desired Solution
Given that a JSON object can be produced with the corresponding song IDs and queue name, it would seem that there shouldn't be issues with parsing through whatever is saved and repopulating the queue list.

The details listed in GitHub issue #11 would need to take precedence here, as there's also no way to edit individual songs within an existing queue.

Images
Image 1: an edit button on individual queues, which should on click...
Image 2: ...provide a user with the list of songs associated with that queue.

[G-flat]

@TCHalogen, I have a question regarding the functionality of the edit button.

When you press 'Play' for a queue, the playlist in the song selection screen would be filled with the songs from that queue. When you click 'Edit', it would do the same thing. What additional functionality would you like the edit button to have?

A feature that I could think of for that button is the following: When you click it, you enter an editing mode for that queue; after you make changes and press 'Save', you alter the queue you've selected to edit and you exit from that mode. Outside of that mode, any changes you make to the current queue would be saved as another queue.

[TCHalogen]

After looking at this again, I'm going to open an additional issue involving the process of queueing, likely today after work -- as there is another bug that reduces overall usability.

With regards to your question: you're right - they technically have the same workflow. You can repurpose the button to say "Play/Edit", then work on #11 to allow for single-song modification within the queue itself. Changing the use of the Save button dependent on the event handler used to call the queue list adds usage ambiguity, which is not a good idea imo. I don't think there's a need to go too complex beyond that.