Add support for Renaming, Copying, and Deleting Loadouts

[Peechey]

Description of the problem being solved:

Initial impl for Renaming, Copying, and Deleting Loadouts. Also allows creating a New Loadout from current active sets. There are a lot of changes from over a year of off and on dev so I don't remember everything and I'm gonna comb through it over the next days. Getting eyes on for optimizations, improvements, testing, and other questions about dumb things I'm probably doing.

There is commented code I need to remove, unused variables likely, and more comments to add.

Concerns/Questions for Maintainers

• Build.lua 324 ish. I'm reusing the copy and kind of delete functions from the SetListControls of each respective type. So I'm basically making headless ListControls every single time we click anything in the Loadouts dropdown. I don't know if that's okay or a performance tank or overall bad but it's there. Maybe I can update it to only create those for when we need them aka when it's one of the functions? This has been updated to only init the ListControls during Copy and Delete.

• Speaking of Build.lua the Loadout logic is starting to really grow, is there a way to move this to its own file and load it in to Build instead for clarity?

• The DeleteByIndex functions I made for each ListControl is only because I want one popup confirmation for all 4 deletes and not trigger 4 separate confirmations if I were to call the OnSelDelete of each ListControl. However these are identical functions inside of the popup wrapper, is there a way to reuse OnSelDelete and bypass the confirmation?

Test Cases

For every test, I'm using an exact match Loadout and an identifier Loadout. Double the loadouts, double the fun. I also found a pob with a ton of loadouts that I'm maniacally butchering.

New Loadout

• Create a new Tree other than Default, verify 2 loadouts exist, Default and newTree -> load newTree -> click New Loadout with existing sets named Loadout 1 -> Expect newTree loadout to disappear and only Default and Loadout 1 to exist as there is no newTree item, skill, config

• Copy Default loadout 3 times for Loadout 1, Loadout 2, Loadout 3 -> manually change Tree to Loadout 1, Item to Loadout 2, Skill to Loadout 3, and Config to Default -> click New Loadout with existing sets renamed Loadout 4 -> expect new Loadout 4 to exist in the list and the other Loadouts unchanged

Rename Loadout

• Rename Loadout Default to Loadout 1-> verify only one loadout named Loadout 1 and all sets match the title
• Create two loadouts, Default and Loadout 1, reorder Tree and Item/Config/Skill Sets so the 2nd loadout's sets are now index 1 -> Rename Loadout 1 to Loadout 2 -> Verify Loadout 1 affected and not Default

Copy Loadout

• Copy Default loadout, given name Loadout 1 -> verify both Default and Loadout 1 exist and are correctly linked
• Same as rename, reorder sets among 2+ loadouts -> Copy Loadout 1 to Loadout 2 -> expect Default and Loadout 2
• From example build, copy Act 1 loadout to Act 1 Copy and verify all sets were perfectly copied, items, skills, etc.
• From example build copy ???c budget loadout to ???c budget Copy and verify all sets

Delete Loadout

• Same as rename, reorder sets among 2+ loadouts -> Delete Loadout 1 -> expect Default only to exist
• Delete Default when it's the only loadout -> verify nothing explodes
• Delete Act 1 Copy and ???c budget Copy from previous tests :D and make sure the correct loadout was deleted

Misc

• One tricky scenario involved fresh build -> copy default -> copy default -> rename copy or delete and it was grabbing the wrong Loadout/not the selected Loadout in the dropdown. So I've thrown a lot of combinations together of reordering sets, deleting loadouts, renaming loadouts, making New Loadouts with Existing, and copying loadouts to make sure there isn't some weird behavior after a set number exist
• With the example build, New Loadout with Existing of multiple different sets and verify the correct sets were copied over
• Verify EditControls are auto-focused on popup for New Loadout, Rename Loadout, and Copy Loadout

https://pobb.in/T47GaMiKN7pX

After screenshot:

Delete has a confirmation

[FenikSRT4]

I don't want to steal your thunder, but my implementation of this adds a new ListControl and refactors many of the commonly used functions between the other list controls to accomplish all of the copying/renaming etc

#9647

[Peechey]

Relieved not to be the only one adding more features to Loadouts! If anything, I'm upset with myself for not thinking of making a new SetListControl 😄 . Yours fixes a lot of the issues I was having with this PR, really, and we're wanting a better UX anyways and I feel like yours is the right direction. I'm a little stuck in my old design.

[FenikSRT4]

I haven't been using PoB very long, but one of the most confusing pieces to me was the loadouts, and how the tree/config/item/skills all had to share the same name. I'm thinking of a different structure to help with the problem of "my loadout doesn't exist when I rename X."

If you want to move forward with my PR and have any suggestions for testing, I'd love for the feedback!

[Peechey]

We do have a second matching rule involving an "identifier" using curly braces that I wrote a little about in the Help section but it's overall still rugged, yeah. Absolutely open to a better solution to that, I generally went with the best idea I had back when this was first introduced. It's been better than nothing, but I'm sure users and build creators especially would welcome improvements.