Site Editor: Add global styles to export file

[Mamaduka]

Description

Fixes #27528.

Adds global style settings (as theme.json) to the site export file.

P.S. I'm preparing the WP core patch for the missing export REST API. I think this will be a good addition to the functionality. We can polish the export feature after 5.9 - #27941.

How has this been tested?

1. Go to Appearance > Editor
2. Open the "More tools and Options" dropdown and export.
3. Confirm that the archive contains the theme.json
4. Confirm that user-applied changes are correctly exported.

Types of changes

Enhancement

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[annezazu]

Just wanted to say thank you for working on this <3

[carolinan]

When I export Twenty Twenty-Two (GitHub version, not WP trunk) without changes the resulting theme.json is not valid.
Colors, font family and font size are placed inside "theme":
Incomplete example to illustrate:

{
    "version": 2,
    "settings": {
        "color": {
            "gradients": {
                "theme": [
                    {
                        "slug": "vertical-secondary-to-tertiary",
                        "gradient": "linear-gradient(to bottom,var(--wp--preset--color--secondary) 0%,var(--wp--preset--color--tertiary) 100%)",
                        "name": "Vertical secondary to tertiary"
                    },

gist with complete output:
https://gist.github.com/carolinan/f5688bd10229d554e8df28688d28aa9d

[Mamaduka]

Thanks for testing, @carolinan.

I'll look into that issue.

[Mamaduka]

@oandregal Is it possible to merge data without setting origins?

[anarieldesign]

Thank you soo much for working on this :). I'll dive into it deeper today and on the first look noticed the same thing @carolinan already wrote

[oandregal]

👋 Took a quick look and this and discussed it with George as well.

It sounds like this feature is useful to export something people can bootstrap themes with. Going with that, it makes sense, in my view, to export the result of merging only theme and user data.

This is straightforward for the styles key. It's also for most of the contents of the settings key, which will end up being the theme's as the user can modify anything so far. The only thing that I see as debatable is the content of the presets, in particular, the content of the colors which can be modified by the user. Should settings.color.palette and settings.color.gradients contain only the user modifications? Or should they contain the theme colors plus the user modifications? It sounds like we'd want the latter (theme+user).

At the moment, we don't have a way to merge color.palette.theme and color.palette.user into one. This should be done in this PR. However, I also want to share that, as per the feedback received #36556 we need to update the palette editor (the component of the global styles sidebar that allows users to edit colors) to behave like this: users can edit the value of any color from the default or theme palettes, and also can add new colors to the custom palette. This is going to require some changes to the data we store in the database and/or the existing merge algorithm. There's going to be a PR for this soon. So, we can either land this adding that merging logic and refactor later or wait for that change.

[carolinan]

+1 for contain the theme colors plus the user modifications,

[Mamaduka]

Closing this PR in favor of #39048.