[base] POC: Allow customizing generated class names

[michaldudak]

This PR introduces the ClassNameConfigurator - a utility that lets developers change the pattern of generated class names (or even disable them at all).

[mui-bot]

Details of bundle changes

Generated by :no_entry_sign: dangerJS against 54c0cc3291401af9060185096c04b283e77021a6

[oliviertassinari]

Is it different from #29051?

[michaldudak]

Yes, this solution does not use a global singleton, so it's better suited for the problem originally described in #28550. Additionally, it can also affect state classes (like Mui-disabled), unlike #29051.

[oliviertassinari]

so it's better suited for the problem originally described in https://github.com/mui/material-ui/issues/28550.

@michaldudak From my perspective #28550 should be outside of the equation for this problem. The pain point raised was class name collisions, with Material UI, not with alternate or global CSS. I have tried to propose a couple of alternatives to customizing the class names to solve the problem, using existing APIs designed to solve the problem, e.g. in https://github.com/mui/material-ui/issues/28550#issuecomment-956143844. Now, we never had a reproduction on this issue, so it's hard to know for sure.

[michaldudak]

Sure, this wasn't my main motivation anyway. The primary use cases I had in mind were:

1. Eliminate the unnecessary classes when styling Base components with a solution like Tailwind CSS
2. Modify the generated class names to conform to a pattern used in a project (for example, with lowercase letters only). This also includes white labeling.

[oliviertassinari]

@michaldudak This could make sense :+1:.

Then, I think we only need to assert that the cost of the feature is worth the gain. For the cost, I have in mind the bundle size, runtime or opportunity cost, or code complexity. For the gain, I assume how popular is the request; and how strategic it could be.

[michaldudak]

We discussed this in more detail on the refinement, and we agreed that having the ability to disable the generation of classes altogether (in MUI Base only) is more important. I'm going to split this into two separate PRs - one to disable classes (having a higher priority) and one for customizing the existing ones (possibly to be done by the community if there's a need).

[michaldudak]

Closing in favor of #35963 - the actual implementation.