frontend: Transitions (dock) separation part 1

[tytan652]

Description

Began to split transitions and transition duration storage from the UI.
Also makes the frontend code rely more on transitions UUID even if those are not preserved between sessions for now.

While this PR remove any kind of reliance on index of a transition, it does not overhaul things to rely only on UUID so there is still reliance on the transition name as an identifier. Same for retaining which transition was inserted last.

Motivation and Context

After multiple tries, I finally managed to separated the transitions data from this combobox, now it needs reviews and testings…

The awaited sequel of #7278, but it's the prequel of the expected sequel.

How Has This Been Tested?

Please tests

Types of changes

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[tytan652]

@PatTheMav, please just say to avoid mutator even if we check if present beforehand.

Using diffs for every mutator use make the review less readable and uses too much space that github ends up hiding stuff.

[PatTheMav]

@PatTheMav, please just say to avoid mutator even if we check if present beforehand.

Using diffs for every mutator use make the review less readable and uses too much space that github ends up hiding stuff.

I disagree, it is the correct tool for the job to highlight requested changes exactly where they are requested, including the context of the change. Expanding all changes takes a single click and that's a small price to pay for the improved clarity of changes and keeping discussions local to specific changes.

[tytan652]

I think you are mixing up the code selected and the diff that you explicitly type in the review. I'm talking about the second.

[PatTheMav]

Are default transitions not supposed to be also contained in transitionUuids?

[PatTheMav]

If I understood the C++ docs correctly, erase can take an argument of the key type and will only throw if the comparator itself throws (so providing an std::string key for a non-existent element should just do nothing).

If it is preferred to explicitly use an iterator, I'd rather have that on its own line to make the code more readable, but the shortened form should be sufficient.

I'm more concerned about the second line, as it relies on implicit conversion between char * and std::string. I dunno if that conversion has defined behaviour when a NULL pointer is provided - if it does the code should be safe (as the empty string object will just fail to match anything in the collection).