reorganize or merge settings and ui settings

[miguelgrc]

After #49 UI settings are displayed in collapse elements, for the moment in two different ones. We should come up with a good way of splitting the properties between general/common and field-specific ones. The reorganization requires splitting properties between ui:options and ui:<property> so rjsf's getUiOptions will be very useful for this as it returns all UI options no matter in which of the two ways they are specified. This task will require some small refactoring of some fields and widgets in order to accommodate this.

An option worth considering is merging both schema and uiSchema in one single schema (probably keeping the distinction in fieldTypes and merging after) and passing it to the settings form. Then in the settings we can arrange them however we want. E.g. discrete mode in slider and options and labels (otherwise options and labels would be in different tabs if we follow the correct rjsf way)

[miguelgrc]

We can indeed combine optionsSchema and optionsUiSchema in PropKeyEditorForm and pass combined schema and uiSchema as formData to it from Customize, combining both onChange handlers. Then we can pass a custom ObjectFieldTemplate to sort and present settings appropriately (similar to PropKeyEditorObjectFieldTemplate). This has been tested and works.

However the question now is how to split settings:

• In different tabs or collapsible sections?
• How to arrange them in fieldTypes. For example, in the case of the slider field (add a slider field #82), how to display field value and label together. We could simply combine schema and uiSchema directly into one object in fieldTypes and base the order on that. E.g. we would have ui:labels and then values (note how labels is a ui prop in order to align with rjsf). The rest of the ui settings (to be displayed in a different section) could be put inside ui:options. So basically we can use ui:xx when we want to interleave some ui settings with settings, and use ui:options for the ui settings that will be displayed separately (similar to feat(form): rework ui schema settings #49). If so we would need to change how we use the common ui:label and put it in ui:options.label.
• Should we maintain both single-schema fieldTypes and multi-schema (current) fieldTypes?