Feature request/discussion: Spread UI schema options to renderers

### Is your feature request related to a problem? Please describe.

When using the various renderer libraries (material-renderers, for example) it feels like a lot of functionality is being left behind. The renderers interface with components that have lots of features, and support many use cases with a variety of different props/arguments.

It's a shame that we aren't able to access all of this functionality and pass all of these args from the ui schema to the underlying components. I suspect this was perhaps intentional as to not clutter the ui schema, to keep it simple, and, maybe more importantly, to keep it universal. But what this means is that the functionality in the ui schema ends up being such a small subset of your ui component library's functionality.

### Describe the solution you'd like

Cluttering the schema with every prop from every renderer would definitely not be ideal. It would also ruin the dream of the ui schema being decoupled from the ui renderer. However, isn't there a simple solution to all of these problems?

Consider the addition of a single key (per renderer set) on the ui schema `options`, one which would be passed directly through and spread onto the underlying components, eg

```
// uischema.json
{
type: 'Control',
label: 'Start date',
scope: '#/properties/startDate',
options: {
material: { // this should match the name of the renderer set it will apply to
// if the renderer renders any of these components, it will spread the following objects value onto them
TextFieldProps: { ... },
DatePickerProps: {
showTodayButton: true
},
// ...etc
}
}
}
```

From the renderer side, the diff would also be minimal. The above example could be implemented like:

https://github.com/sarink/jsonforms/pull/1/files#diff-678df4b42a209e09d93f6f548c65e7aeb3eaff2e38448d54aab0396529a93a61

### Describe alternatives you've considered

The only real alternative to this problem is to write your own custom renderer and add custom ui schema options. In the case of needing to add just one prop (eg material-ui's `showTodayButton` on the `DatePicker`), it is pretty unfortunate to have to fork the existing renderer, add one line, then maintain it forever.

### Framework/RendererSet

All