Filter component change API

@AndreyChernykh had some concerns with the design of the `` component's API.

Imagine a Filter that can filter on two drop-down fields: favourite colour (options are: blue, red, orange) and favourite animal (options are: cat, dog, eagle, dragon).

The `data` prop that is passed into `` is an array of objects, where each option must exist in the array or it will not be an `` in the ``. So you must pass in at least this data:
```
data = [
{colour: blue, animal: cat},
{colour: red, animal: cat},
{colour: orange, animal: cat},
{colour: orange, animal: dog},
{colour: orange, animal: eagle},
{colour: orange, animal: dragon},
]
```

This can be a pain for cases like mine, where I have to filter on five (and soon eight) drop-down fields, and each could have dozens of options.

Andrey was thinking instead the API could incorporate `options`, so they don't have to be duplicated over and over again (like "orange" is above):

```

```

cc: @allison-c

No file names are provided, so first locate the `` component implementation and its exported API entry point in the repo. Check how the current `data` prop is currently mapped into option lists for each dropdown, then trace where prop validation/defaults are defined to add support for an `options` prop while preserving current behavior. Update Filter docs/examples and any existing Filter tests to include the multi-field `options` object shape and existing data-array usage. Done means both usage patterns render valid dropdown options for multiple fields and tests/docs reflect the new API.

Escrito por el modelo de indexación a partir del texto del issue.