Add Loadout management UI

[FenikSRT4]

Fixes PathOfBuildingCommunity/PathOfBuilding#9451

Description of the problem being solved:

• Adds Loadout management replacing the single New Loadout option in the loadout dropdown. This new Manage option opens a ListControl menu for creating new, copying, renaming and deleting whole loadouts. This does not change the rules around managing the names for each set that's part of a loadout. For example, renaming an item set still disassociate the loadout.
• Multiple functions that existed in the list controls were refactored to be functions that were part of the respective tab class. ie: Renaming is now a function in ItemsTab as a class function instead of that logic living in the list control
• Several refactors around builds were pulled out of creating the list into functions so they could be reused or called elsewhere.
• This now implements a new type of functionality for mixing and matching loadout properties, named New/Copy Custom. This dialog allows users to select properties from the list of properties for the respective type to copy into a new loadout, or create the property from new. ex: ItemSet from Loadout 1, SkillSet from Loadout 2, Passive Tree from Loadout 3, and a New Config Set.

Related PR from PoB1: PathOfBuildingCommunity/PathOfBuilding#9647

Steps taken to verify a working solution:

Link to a build that showcases this PR:

Before screenshot:

After screenshot:

[Wires77]

Loving the tests, thanks for adding all of those.

The service classes feel out-of-place to add here, especially given the lack of an existing pattern. They're only being used in one place each, and they call back to the owning tab. I expected them to be used in the new Loadouts UI, but even there it just calls the corresponding function in the Tab class directly. I'm curious about your reasoning here.

One thing to update for sure is the Help panel wording.

[FenikSRT4]

Thanks for the feedback!

The service classes feel out-of-place to add here, especially given the lack of an existing pattern. They're only being used in one place each, and they call back to the owning tab. I expected them to be used in the new Loadouts UI, but even there it just calls the corresponding function in the Tab class directly. I'm curious about your reasoning here.

My thought with the service classes were to abstract some of the "detail" oriented logic from the UI layer (List Controls), but not to over complicate the data layer (SetTabs and Build). This allowed me to easily test the end-to-end behavior that would have happened in the UI layer via the service layer. I also felt like this type of architecture is fairly common in software design, so it felt easy to adopt.

Certainly as my solution evolved through development, many of the service function calls served as more of a relay to the data classes. I kept it as a common paradigm through the refactors that I did in case additional logic should be added in a service layer like some side-effects as a result of an update to the underlying data model.

The reasoning for not using the service classes in the BuildSetListControl was because the Build module/class already owned the set tabs, because it's a composing module for the whole UI. I envision a future where the loadouts are abstracted out of this module into it's own data model where they're also saved to the underlying build xmls.

One thing to update for sure is the Help panel wording.

This is a good callout, and not something I had considered. I'll work on some updates.

[LocalIdentity]

Better handling than previous but still need to think about how we want to handle loadouts that use {1, 2} notation to link multiple sets to a single tree / config