Store user ID with setting change written into changeset and restore user when setting is saved

[westonruter]

In researching how best to accommodate Jetpack (#38672) being able to allow users who cannot unfiltered_css to be able to edit Custom CSS by adding additional sanitizing filters, I realized a deficiency in changesets (#30937). A supderadmin user user may write a change into a changeset, such as post_content, and this may include unsafe HTML as intended by the superadmin user. If non-super admin user comes along and makes a change to a different setting and updates the changeset, then if that non-super admin publishes the changes, the kses filters will unexpectedly strip out the unsafe markup content that the superadmin had written in their changeset update. This likewise will happen when a superadmin schedules their changeset for publishing later: when WP Cron runs there is no current user, and so the kses filters would apply then as well.

What is needed is for the user who modified a setting to have their user_id associated with the setting in the changeset. Then when the changeset is published with the settings being saved/persisted to the DB, then the associated user should be logged-in temporarily so that the setting will save with the expected user context. For normal user updates to changesets, this means that settings would no longer need to have their associated capability temporarily overridden to be exist.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/196

[westonruter]

In 39181:

Customize: Store modifying user ID with setting change written into changeset and restore current user when setting is being saved.

Restoring the current user context when saving a setting ensures filters apply as expected, such as Kses. When a user is not associated with a given setting change, continue to override capability to be exist when saving. Skip overwriting setting values in a changeset that have not changed, facilitating concurrent editing and amending a changeset by a user with fewer privileges.

See #30937.
Fixes #38705.

[westonruter]

In 39320:

Customize: Ensure that WP_Customize_Manager::save_changeset_post() returns setting_validities even for supplied values that are unchanged from values in changeset.

Check setting existence and authorization via WP_Customize_Manager::validate_setting_values() even for null values to account for custom params being added to settings, preventing failures from being silently ignored.

See #38705, #30937.
Fixes #38865.