Prevent exporting a partial for selective refresh when user can't preview its settings

[westonruter]

When partials get registered, they are associated with one or more settings, just as controls do. Controls are prevented from being exported to the client if they are associated with any settings that the user doesn't have the capability to update. At the moment, however, partials do not have parity with controls in this way: partials are being exported to the client even if the user cannot make any changes to them. This results in misleading “Shift-click to edit this element.” messages for such users.

So WP_Customize_Partial::check_capabilities() should be created for parity with WP_Customize_Control::check_capabilities(). Partials that don't pass the capability check can be omitted from being exported to the client. These partials can also be rejected from requests to render partials. While these are currently not rejected, they can only be previewed using settings already saved in the DB, since setting changes will be ignored if the user doesn't have the capability: these are currently treated as read-only partial renders.

[DrewAPicture]

@westonruter 35914.1.diff​ Looks good. One thing on the DocBlock for the check_capabilities() method, the return type should just be false if the return is always false.

[westonruter]

@DrewAPicture it also returns true.

[DrewAPicture]

@westonruter Yeah, let me remove my foot from my mouth.

[westonruter]

In 36643:

Customize: Skip exporting partials to client and handling rendering requests if user can't modify associated settings.

Introduces WP_Customize_Partial::check_capabilities() for parity with WP_Customize_Control::check_capabilities().

See #27355.
Fixes #35914.

[westonruter]

In 36650:

Customize: Fix and extend broken ajax unit tests to account for partials being skipped from rendering.

Fixes regression introduced in [36643].

See #35914.