chore(color): refactor the classes used to manage models and labels

[philmoz]

Refactor:

• Rework the classes used to manage models and labels to simplify the interface. The interface is reduced from 3 classes (ModelCell, ModelMap and ModelsList) to 2 by removing the ModelMap class and moving the functionality to the other two. The primary interface object has been renamed modelCellManager to make to code more readable.
• Use storageDirty to mark the labels file for update instead of saving immediately.
• Remove the delete / rebuild of the model management class objects when labels are renamed or deleted. Keeps the ModelCell pointers valid so the manage models page does not need to be rebuilt.

Enhancements:

• prevent invalid characters from being entered with the keyboard when creating labels (instead of deleting after entering the label).
• when a model is duplicated a unique name is set on the new model based on the current name and focus is set to the new model button in the manage models UI.

[pfeerick]

• when a model is duplicated revert the name of the new model to the default name (MODELxx) and set focus to the new model button in the manage models UI.

This is because it would be harder to figure out what numerical number to add to the end to differentiate? As I don't see having to re-enter "Skyhunter" a second time if I duplicate the model as an enhancement (let alone anything more complex naming). If so, I get it, but it certainly isn't an enhancement.

[philmoz]

• when a model is duplicated revert the name of the new model to the default name (MODELxx) and set focus to the new model button in the manage models UI.

This is because it would be harder to figure out what numerical number to add to the end to differentiate? As I don't see having to re-enter "Skyhunter" a second time if I duplicate the model as an enhancement (let alone anything more complex naming). If so, I get it, but it certainly isn't an enhancement.

Well I thought it would be better than having multiple models all with the same name; but yes it would be better to try and append a unique number to the current name.

If there is no space for a unique number would it be better to fall back to the default name or truncate the current name to make room?

[pfeerick]

Well I thought it would be better than having multiple models all with the same name;

I am in full agreement on that!

but yes it would be better to try and append a unique number to the current name.

If there is no space for a unique number would it be better to fall back to the default name or truncate the current name to make room?

The easy option is to fall back, but truncation preserves as much of the original name as possible. It may even be worth considering splitting that behaviour out of this PR, as ideally you want bw and colorlcd to behave the same way, so may require changes there to keep from introducing diverging behaviours (in a PR ostensibly focused on colorlcd refactor)?

[philmoz]

The easy option is to fall back, but truncation preserves as much of the original name as possible. It may even be worth considering splitting that behaviour out of this PR, as ideally you want bw and colorlcd to behave the same way, so may require changes there to keep from introducing diverging behaviours (in a PR ostensibly focused on colorlcd refactor)?

The issue with B&W is the model duplication is done by just physically copying the model yaml file.
The rename is possible now with color radios because of the ability to rewrite the model file without mangling the active model data. This isn't an option for B&W at the moment.

[philmoz]

Updated to try and generate a unique name from the current name by appending a number as "(x)" to the current name.
If the current name is too long it is truncated and if a unique name can't be created it falls back to the default.