CompatibilityChecker must check object properties

First proposal pushed. I twas a big work, bigger than expected, but a necessary work.

The main fix:

1. Many tests were added to tests/fixtures/CompatibilityCheckerData.yml to cover the situations when we want to check the inner properties of a JSOn object, so for AttributesPropType and LinksPropType
2. In src/SchemaManager/CompatibilityChecker.php, we are now looping on object properties (and patternProperties) and checking their compatibility.

However, something was still wrong, some tests (automated or manual) were still KO. Because the current logic of JSON schema resolving in ComponentPluginManager was done separately from the CompatibilityChecker, with only a specific "conciliation" check for the root of the prop schema.

We didn't notice that until now because the only cases with JSON schema references not in the root of the prop schema were... LinksPropType ;)

So, other fix:

1. We moved the specific check from src/ComponentPluginManager to src/PropTypePluginManager
2. This check is now run after ReferencesResolver::resolve() so we are testing id property instead of $ref
3. We keep running ReferencesResolver::resolve() in ComponentPluginManager but we add a call from src/SchemaManager/CompatibilityChecker.php, before calling Canonicalizer::canonicalize() in order to be sure both schema are resolved, so comparable.
4. We have updated ui_patterns.services.yml to tests/src/Unit/SchemaManager/CompatibilityCheckerTest.php to inject the ReferencesResolver to CompatibilityChecker
5. A little change in Canonicalizer::canonicalize() because ReferencesResolver sometimes transform arrays in StdClass.

Liam, is this MR fixing your issue?

---

Mikael, Christian, let's talk before merging.

This is a big change, in a deep, tricky and strategic part of the module, so lets' be extra careful.

Let's also check the performance because the mechanisms altered are processing heavy. I don't believe the change will hut performance (I kind og hope they may improve it a bit), but let's also be careful there.

I am not able to reproduce the problem anymore. The site is in major development.

Don't worry, your input was very useful to identify an issue which have been hidden for one full year. Thanks a lot.

Can you tell me more? What is the component prop definition?

This prop schema:

label:
  type: ['string', 'null', 'boolean']

Can be caught by:

• BooleanPropType plugin which is expecting type: 'boolean'
• StringPropType which is expecting type: 'string'

Both plugins have the same priority level ("1") so the alphabetical order is ruling the discovery and this prop is managed by BooleanPropType.

My guts feeling is to ask: why ['string', 'null', 'boolean']? I struggle to understand what this schema is trying to achieve here, because the prop is only used in:

{% include 'radix:heading' with {
  content: label,
  ...
} %}

And heading's content prop has type: string schema. So, it may look like somehtign related to component authoring.

But our philosophy in UI Patterns is to adapt our logic to component implementations found in the wild, instead of dictating component authoring. We will not ask you to change the definition to fit with better with our module. So, maybe playing with priority order, to be sure the prop is maanged by StringPropType plugin, can be evaluated.

Rebased.

As said before, this is a big change, in a deep, tricky and strategic part of the module, so lets' be extra careful.

Let's also check the performance because the mechanisms altered are processing heavy. I don't believe the change will hurt performance (I kind of hope it may improve it a bit), but let's also be careful there.

This fixes the breadcrumbs for me. It does not fix the block titles, which still appear as "1".

The MR is addressing the links issue and it is fortunate (but not that surprising) it also fixes #3510711: Links prop type is detected before Breadcrumb adapter.