Update WP_Theme_JSON API so presets are always keyed by origin

[oandregal]

This PR updates the implementation we introduced in #32358 so presets are always keyed by origin.

What's the issue

In #32358 we updated the internal shape of the presets to be keyed by origin, one of core, theme, user. While consumers (core, theme, user data) continue to use the unkeyed format via a theme.json structure, internally, we adapted it to become:

{
  "color": {
    "palette": {
      "core": [
        { "slug": "color-1", "value": "value-1" },
        { "slug": "color-2", "value": "value-2" }
      ],
      "theme": [
        { "slug": "color-3", "value": "value-3" },
        { "slug": "color-4", "value": "value-4" }
      ],
      "user": [
        { "slug": "color-5", "value": "value-5" },
        { "slug": "color-6", "value": "value-6" }
      ],
    }
  }
}

One of the unintended consequences of that PR was that we made a requirement for consumers of the API to pass the data through the merge method ― otherwise the presets won't be in the proper shape. This piece of code:

$theme_json = new WP_Theme_JSON( $some_data_here );
$theme_json->get_settings();

would yield:

{
  "color": {
    "palette": [
      { "slug": "color-1", "value": "value-2" },
      { "slug": "color-2", "value": "value-2" }
    ]
  }
}

Instead of:

{
  "color": {
    "palette": {
      "theme": [
        { "slug": "color-1", "value": "value-2" },
        { "slug": "color-2", "value": "value-2" }
      ]
    }
  }
}

What this PR changes

This PR assigns an origin in the object constructor instead and uses it to adapt the preset shape as part of the initial processing. Then, the merge algorithm is updated to simply make the origin part of the path to the setting.

How to test

I've tested a number of scenarios in the post & site editors using TwentyTwentyOne and TT1-blocks:

• a theme that does not define any color palette => core colors are shown
• a theme with an empty array as color palette => no colors are shown
• a theme with a color palette => the theme colors are shown
• add user colors via the site editor => the modifications are shown everywhere

I've also verified that the classes and custom properties for core are present in addition to theme CSS.

As with #32358 this should be tested with 5.7. In WordPress 5.8 the list of colors shown include both core and theme, but this is expected because this reverts a change we landed in 5.8 and we still need to port it to core ― once we do, it'll work as 5.7.

[youknowriad]

I'm approving but I honestly don't really know how to test this properly (the palettes seem to work with or without it)

[jorgefilipecosta]

Not all presets are keyed by origin, only colors, gradients, font sizes, and font families are. For example, duotone is not. I think we need to take that into account inside the look.

[oandregal]

duotone is not part of PRESETS_METADATA as far as I can see?

[youknowriad]

should all presets be keyed? Why have special cases?

[jorgefilipecosta]

duotone is not part of PRESETS_METADATA as far as I can see?

Yes, I wrongly thought it was part of presets metadata.

should all presets be keyed? Why have special cases?

The rationale was that duotone was dynamically injected there was no need to output class variables etc. Also, duotone does not references or contains a name the direct colors are store in attributes "duotone":["#000097","#ff4747]. We don't have a need for this system there. But for consistency reasons, we may reconsider.

[jorgefilipecosta]

Thank you for this enhancement it worked well on my tests 👍