EZP-31647: more flexibility added to AttributeMapper::supports

[SerheyDolgushev]

Question	Answer
JIRA issue	EZP-31647
Bug/Improvement	yes
New feature	no
Target version	2.0
BC breaks	no
Tests pass	yes
Doc needed	yes

Before this PR EzSystems\EzPlatformRichText\Configuration\UI\Mapper\CustomTag\AttributeMapper::supports was accepting only $attributeName. But in some cases, it is vital to have attribute mappers for specific custom tags/attributes.

TODO:

• [x] Implement feature / fix a bug.
• [x] Implement tests.
• [x] Fix new code according to Coding Standards ($ composer fix-cs).
• [x] Ask for Code Review.

[SerheyDolgushev]

@alongosz can you please review this one?

[SerheyDolgushev]

It is a feature request.

Let's say there are two custom tags with my-choice choice attribute:

1. Custom tag tag-A where the list of possible options for my-choice attribute is static
2. Custom tag tag-B where the list of possible options for my-choice attribute is dynamic, let's say it is fetched from some 3rd party API.

Right now it is possible to have an attribute mapper for all the choice custom tag attributes. But it is impossible to have an attribute mapper for just a specific attribute of the specific custom tag. This PR provides this feature and will let to have an attribute mapper only for the my-choice attribute of tag-B custom tag.

@alongosz please let me know if you have any questions.

[alongosz]

Hmm, this feature (as always) can go in master only. We also need to decide then to expose AttributeMapper as a strict contract, to be discussed with @ezsystems/php-dev-team how/where. Not sure when this is gonna happen, because we're all quite busy now and API extension point design is not an easy thing to assess. I'm also not 100% sure it's not gonna mess up existing code. You can reach out to @SylvainGuittard to see if he can prioritize this.

For now what is required are some configuration examples and unit test coverage.