rewrite api doc for FormWidget and FormValueWidget, fixes #18363

cc @AdrianVasiliu 

Hopefully this addresses all the points you brought up.  You can add some inline comments if you see places for further clarification.
> So, I will revert that addition to the doc, and just say something less specific like that FormValueWidget is for widgets that want to emit synthetic change/input events.

Well, this would escape from the difficulty, but at the price of keeping things fuzzy. 
I would propose to keep this slightly amended variant of your initial prose:
"FormValueWidget shouldn't be used for widgets that extend or embed native form elements such as `<select>`, because in that case the "change" and "input" events are already emitted naturally by the browser."
(I removed the paranthesis around "such as `<select>`" to avoid giving the impression it shouldn't be used for widgets embedding native form elements in general - `<input>` is also a native form element, and subclasses of FormValueWidget do embed `<input>`). 

What would further help would be bring some guidance for a widget embedding `<input>` and needing the handleOnChange/handleOnInput helper methods because "input" and "change" are not emitted naturally at the appropriate moments or with some settings (as it is the case for the Combobox), while "input" and "change" events happen to also be emitted naturally by `<input>` when the user types and with some settings of the widget. Maybe it's as simple as prevent-defaulting these "spurious" input/change events? The bottom line is that the doc of Form(Value)Widget is supposed to guide developers implementing subclasses (their own form widgets), and it would be nice that it brings a bit more guidance for less simple situations.