Customize: Add REST API endpoints for panels, sections, controls, settings, and partials

[westonruter]

In order to make the customizer a REST API-backed application, the objects that it uses need to have REST API endpoints. In addition to having an endpoint for changesets (#38900), there should be endpoints for getting a list of the panels, sections, controls, settings, and partials. One immediate benefit for these endpoints will be to allow for the objects to be lazy-loaded when needed (#28580) to improve performance. Having schemas attached to WP_Customize_Setting would also allow controls to be generated automatically with the appropriate validation constraints (#38845). This will also facilitate bootstrapping the customizer onto the frontend so that customization can be done without going to customize.php.

Feature plugin repo: ​https://github.com/WP-API/wp-api-customize-endpoints

+1. This could be useful internally for the core customize app and also externally, and extend the current API by respecting the to_json() stuff that objects are already doing. I'd see a goal here be to generate the customize object json via the API instead of directly; however, there needs to be some demonstration of why using the API is better.

Using the REST API as the interface for obtaining the configurations may not be better for customize.php's exporting to _wpCustomizeSettings, especially in the case of serializing out a LOT of data in one big chunk which had major performance problems as shown in #33898. In that regard, we may actually want to consider proposing a REST API improvement to \WP_REST_Server::serve_request()). We'd need to ensure that we still serialize out each JS object separately for the sake of memory. But also I hope that with a REST interface for obtaining settings and controls, we'd be able to lazy-load these via #28580 as needed (e.g. when the panel expands) rather than load all of this data up front which can incur a heavy server load to generate the initial customize.php response. We could do internal REST API calls to /customize/settings and /customize/controls etc instead of looping over these manually directly with PHP.

Moving to 4.8.1 while development continues on the GitHub repo.

Note: starting working on the ticket.

As noted in #38900, work on this will continue in feature plugin and be tested during the development of a planned Customizer v2 feature plugin. No need to get this merged into core before feature plugin fully utilizes it in core.