Let WP_Customize_Manager::add_setting() honor filters added for dynamic settings

[westonruter]

In 4.2, the Customizer added support for dynamic settings (see #30936). Dynamic settings are those which are created via JS on the client (e.g. widget instances or nav menu items) and then sent to the server along with any statically-added settings that have changes. Settings can be represented by any number of subclasses forWP_Customize_Setting, for instance nav_menu_item[...] settings are represented as WP_Customize_Nav_Menu_Setting classes.

Nevertheless, when you add a new setting via: WP_Customize_Manager::add_setting( $id, $args ) the class used is hard-coded to be WP_Customize_Setting. This means that if a plugin has specifically added a filter to use a specific WP_Customize_Setting subclass for a given setting ID, then this will not be honored when add_setting() is called.

I propose that WP_Customize_Manager::add_setting() be made to explicitly support dynamic settings by applying the customize_dynamic_setting_class (and customize_dynamic_setting_args) filters.

[westonruter]

Unit testing

[westonruter]

In 35810:

Customizer: Apply customize_dynamic_setting_class and customize_dynamic_setting_args filters in calls to WP_Customize_Manager::add_setting( $id, $args ).

Ensure that plugin filters apply as expected for any settings registered statically without passing in an explicit class instance to WP_Customize_Manager::add_setting().

Fixes #34597.