Add support for new syntaxes in CKEDITOR.tools.color

[Comandeer]

What is the purpose of this pull request?

New feature

Does your PR contain necessary tests?

All patches that change the editor code must include tests. You can always read more
on PR testing,
how to set the testing environment and
how to create tests
in the official CKEditor documentation.

This PR contains

• Unit tests
• Manual tests

Did you follow the CKEditor 4 code style guide?

Your code should follow the guidelines from the CKEditor 4 code style guide which helps keep the entire codebase consistent.

• PR is consistent with the code style guide

What is the proposed changelog entry for this pull request?

* [#4583](https://github.com/ckeditor/ckeditor4/issues/4583): Added support for new, comma-less color syntax to [`CKEDITOR.tools.color`](https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_tools_color.html).

What changes did you make?

I've added support for several new syntaxes:

• 4-HEX,
• RGB with alpha,
• HSL with alpha,
• RGB & RGBA without commas and with alpha channel preceded by /,
• HSL & HSLA without commas and with alpha channel preceded by /,
• hex-like values.

Which issues does your PR resolve?

Closes #4583.

[sculpt0r]

Besides code comments I'm thinking about two things:

• we should add getters for hex-like value format (with & without alpha). With this, we can avoid using getHex() and then trim # in other places. If sth change and we will need to use color code with hash, we can change used getter, and don't need to play again with strings with/without leading #. We just take a specific format to displays it. It looks like sth useful for our color-related widgets.
• we could add getters to format rgb/hsl without commas - but it is something, I'm not very convinced. Maybe if we don't need it now - we can live without it?

[Comandeer]

Rebased onto latest major.

[Comandeer]

• we should add getters for hex-like value format (with & without alpha). With this, we can avoid using getHex() and then trim # in other places. If sth change and we will need to use color code with hash, we can change used getter, and don't need to play again with strings with/without leading #. We just take a specific format to displays it. It looks like sth useful for our color-related widgets.

I'm not sure if it should be a new method or just a parameter to getHex (like withHash).

• we could add getters to format rgb/hsl without commas - but it is something, I'm not very convinced. Maybe if we don't need it now - we can live without it?

The same here – maybe just introduce parameter to existing methods?

We could make our getters take an options parameter – that way it would be the most extensible solution. However I'm not sure if we really need it right now – maybe we can extract it to the new issue?

Beside that, I've fixed other raised issues.

[sculpt0r]

We could make our getters take an options parameter – that way it would be the most extensible solution. However, I'm not sure if we really need it right now – maybe we can extract it to the new issue?

Parametrized getters sound good to me :) 🤔 Based on @Dumluregn sentence (about making API for a certain purpose), we probably should wait with this for #4592. It will be a good time to additionally adjust API.

Beside that... LGTM 🎉