Consolidate WP_Theme_JSON_Resolver changes in both lib/compat/wordpress-6.0 and lib/experimental

[oandregal]

What?

This PR does two things:

• makes sure the lib/compat/6.0/wp-class-theme-json-resolver-6.0.php has all the changes to be backported.
• makes sure the lib/experimental/wp-class-theme-json-resolver-gutenberg.php has all the changes to be backported and the experimental ones.

Why?

By the process we have, we add changes to lib/compat/6.0 when they are supposed to land in WordPress 6.0 and we add them to lib/experimental when they need more iteration and should not be backported. This is problematic when the same method contains both experimental changes and changes to be backported.

This is the case of WP_Theme_JSON_Resolver_*::get_theme_data method, that has changes to be backported and others that should not.

How?

The get_theme_data method in experimental is the one that will run, so it needs to have all the changes necessary to work well.

On the other hand, we also need all those changes (but the experimental ones) in the get_theme_data method of lib/compat/6.0, as to make sure they're backported. Though this method is not called.

Alternatives:

1. Continue the separation. Identifying changes to be backported requires looking at lib/experimental, git history and understand what everything does. Every change to be backported for a method that needs experimental changes needs be ported at experimental.
2. Add a hook _lib_experimental_changes_description that code at lib/experimental could use. We'll still need to mark the hook as not to port, so I thought why not doing it directly given it's a oneliner.
3. Merge both classes into a single one (living in lib/compat for example) and mark the changes not to backport via comments, as in:

/* NOT TO MERGE IN CORE (START) */
changes_go_here();
/* NOT TO MERGE IN CORE (END) */

Future

This PR tries to work with the model we have now to make sure everything is contained (we know what to backport) and it works (the experimental method has all the changes).

The existing approach has some pros:

• we still have the experimental changes marked in lib/experimental

It also has some cons

• requires porting every change to this method to both the lib/experimental and lib/compat/wordpress-6.0

For now, given how close we're to the WordPress 6.0 cutoff, it seems easier to run with what we have. For the 6.1 cycle this may require further thinking and/or changing the approach to avoid changes not being backported.

[oandregal]

To be clear: I think we need to keep the separation between lib/experimental and lib/compat. Just in this specific case we can't easily.

[oandregal]

Initially, I thought merging both resolvers was easier. But it also has cons: we no longer have the experimental changes in lib/experimental but we still need them for the 6.1 cycle. I've modified the direction of this PR to just have both methods to contain all the feature changes to be backported but only the experimental method has the experimental changes.

[scruffian]

LGTM