Phase out `w-field--{snake_cased_python_class}` classnames

[sag​e]

I would like to push for our use of w-field--{some_snake_cased_python_class} classnames to be phased out. They create a coupling between "how server-side form logic is implemented" and "how a given widget should be styled" that really shouldn't be there. See #9320 for a previous case where this has bitten us - in fact the MRO fix was suggested there too, but that wouldn't help for cases where two widgets need to be styled the same way but have very different inheritance chains on the Python side, such as a chooser that chooses items from an API rather than a local model and therefore needs to be an IntegerField rather than a ModelChoiceField. (This was also acknowledged on that PR discussion, but doesn't seem to have made it into the fix itself - even after that PR was merged I've still had to fake it with a classname = "w-field--model_choice_field" to get the right styling).

If a form widget needs a classname for its styling, it should set one explicitly (and give it a name relevant to the styling that needs to be achieved) rather than rely on an automagically-set classname based on the Python code.

If it's not possible purely with CSS selectors like input[type="radio"] (and I'm sure you wouldn't be asking if it was :-) ), we can define subclasses of the vanilla widgets with the classnames in place, and register them as overrides so that they get used as standard for forms inheriting from WagtailAdminModelForm. (AdminAutoHeightTextInput in particular is a good example of a subclass that adds a classname and not much else.)

We can probably create a similar mechanism for non-model forms if needed - although since those specify fields explicitly, it's probably not a big deal to say "here are Wagtail's widget classes, use them in your form definitions if you want them to be styled correctly".

Originally posted by @gasman in #11615 (comment)