Customizer control subclasses (custom controls) should have all parent control types as html classes

[celloexpressions]

See ​https://wordpress.slack.com/archives/core/p1418599325001596. This will let us simplify our css selectors, and make it easier to create custom controls without duplicating core css. Particularly notable with the core media controls, which are nested several levels deep ((potentially-in-the-future media) -> upload -> image -> background-image/header-image).

[celloexpressions]

Render html classes for the entire sub-class tree's types, clean up core CSS selectors accordingly for media controls.

[celloexpressions]

Whichever is committed second between this and #29215 will need to be updated to making the only remaining CSS class for the media controls .customize-control-media. This shouldn't have any back-compat issues since we're adding new classes and keeping the existing ones in place as well, unless anyone was relying on the previous way parent class types were scoped in.

[ocean90]

IMO the order of the class names should be inverted. Instead of

customize-control customize-control-header customize-control-image customize-control-upload

it should be

customize-control customize-control-upload customize-control-image customize-control-header

[DrewAPicture]

@celloexpressions, @westonruter: Can we can get an update and some movement here?

[celloexpressions]

I couldn't figure out any other way of doing this, and there wouldn't be an easy way to reverse the order with this approach. So we either need to just go with it, or punt and try to come up with a new approach.

[DrewAPicture]

Patch needs to be refreshed, and feedback from @ocean90 addressed. We're going need a new patch pretty soon or punt to a future release and take another shot at it.

[ocean90]

Still no new patch, punting.

[celloexpressions]

Related: #30618 now has an approach that allows the mess of media control selectors to be removed. While I still like the idea of including parent classes as html classes for a variety of reasons, the only technical implementation that I could find was the patch above which, as noted above, is concerning.

I'm going to close this as maybelater for now and we can revisit if a better solution emerges. In the meantime, workarounds like the one on #30618 are possible, if inconvenient.