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.
And here's how it goes for deliteful/Combobox: as agreed, it should extend FormValueWidget, and use handleOnChange/handleOnInput to fire "input" and(/or) "change" events. That basically works smoothly. The events will be fired only when the widget calls these methods, after user-interaction (click on options). So far so good, but the widget also has a mode (autoFilter=true) where the user can type into the embedded `input` element. When doing so, the `input` element fires "input" and "change" events by itself... 

The trouble is that, according to the (new) doc, "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". All in one, it would mean Combobox should extend FormWidget or FormValueWidget depending on the value of its autoFilter property?... I tend to think the hybrid situation of this widget is kind of yet another argument for my suggestion to merge FormValueWidget and FormWidget.