Fix: Rest global styles controller accessing config that may not exist

[jorgefilipecosta]

After a fix on #35801 the post is now created on the database by "get_user_data_from_custom_post_type" as {"version": ' . WP_Theme_JSON_Gutenberg::LATEST_SCHEMA . ', "isGlobalStylesUserThemeJSON": true }. And I think it is right by default the user has no settings and styles.
Our code was assuming that on the database existing settings and styles were always present by unconditionally doing $config['settings'] = $existing_config['settings'] when $existing_config['settings'] may not exist.
In the case where $existing_config['settings'] did not exist there would occur a PHP warning and on the database, we would then serialize { settings: null }. Settings being null is not something the frontend code that compiles the styles accepts and as a consequence no global styles would be output at all. As a different issue, we need to make sure that if user global styles are not valid theme styles are still output.

How has this been tested?

Delete the current global styles post if there is any.
Open the site editor and change the global background color.
Verify global styles are still output on the frontend (on trunk they are not).

[youknowriad]

Do you think it's worth adding a unit test about this case?

[jorgefilipecosta]

Do you think it's worth adding a unit test about this case?

Yes, I think testing this may be useful I will look into expanding our API test cases.

[youknowriad]

Looks like this PR introduced some linting issues on trunk