Improve alignment between settings params between Customizer Controls and Partials

[westonruter]

In #27355, the concept of a Partial was introduced and is analogous to a Control in many ways, particularly in that it an object associated with one or more settings. A control is instantiated in JS like:

var control = new wp.customize.Control( 'foo', {
    params: {
        setting: 'default',
        settings: { 'default': 'foo', 'bar': 'bar' },
    }
});

Whereas a partial is instantiated like:

var control = new wp.customize.Partial( 'foo', {
    params: {
        settings: [ 'foo', 'bar' ],
        primarySetting: 'foo'
    }
});

Note the difference in how a partial uses primarySetting to designate the main setting for a control, whereas a control has a secondary “setting key” which is used identify which of the settings in the object passed should be the main setting.

Personally, the way settings are passed to Controls is not very intuitive to me, but to improve the parity in the API, perhaps both styles should be accepted by the partial.

[celloexpressions]

This is specifically introduced in 4.5/trunk.

I think it could be nice to have parity here, but on the other hand with it not being in 4.5, not sure that it's worth changing later, particularly given the relative complexity of the patch. If anything, since the partial approach is clearer, we may want to update controls to accept that so that we're moving toward a clearer API.

[westonruter]

In 41750:

Customize: Allow controls to be created with pre-instantiated Setting object(s), or even with plain Value object(s).

• Allow passing settings in keyed object (e.g. settings: { default: 'id' } ), or as an array (e.g. settings: [ 'id' ]) with first being default; again, Setting/Value` objects may be supplied instead of IDs.
• Allow a single setting to be supplied with just a single setting param, either a string or a Setting/Value object.
• Update changeset_status and scheduled_changeset_date to be added dynamically with JS and simply passing of api.state() instances as setting.
• Introduce a data-customize-setting-key-link attribute which, unlike data-customize-setting-link, allows passing the setting key (e.g. default) as opposed to the setting ID.
• Allow WP_Customize_Control::get_link() to return data-customize-setting-key-link when setting is not registered.
• Eliminate default_value from WP_Customize_Date_Time_Control since now comes from supplied Value.
• Export status choices as wp.customize.settings.changeset.statusChoices.
• Export date and time formats as wp.customize.settings.dateFormat and wp.customize.settings.timeFormat respectively.

Props westonruter, sayedwp.
See #39896, #30738, #30741, #42083.
Fixes #37964, #36167.

[westonruter]

In 42031:

Customize: Improve Media control accessibility and compatibility for settings passed as arrays or as solitary setting.

• Eliminate Media control template from having dependency on params.settings.default for element ID, to fix compat with params.settings array or single params.setting. See #36167.
• Move description out of label and add aria-describedby to Media control's Select button. See #30738, #33085.
• Obtain notification container whenever content is (re-)rendered (such as for Media control). See #38794.
• Re-render notifications after control content is re-rendered, if control is in expanded section. See #38794.

Amends [41390].
See #36167, #38794, #33085, #30738.

[westonruter]

Dev note: ​https://make.wordpress.org/core/2017/11/01/improvements-to-the-customize-js-api-in-4-9/