[docs] Add an example for a fully customized filter panel outside the grid

[joserodolfofreitas]

Motivation

Users are looking for a way to fully customize the filter panel and their inputs.

"We are looking to move the filter panel to a new location, that is static, and always showing, ideally above our DataGrid table. Is it possible to customize the Filter panel in that way? I could not find any resources online for the above use case."

The panel only works inside the DataGrid currently, but we can support users to build their own filters with a good example. The following codesandbox is a start: https://codesandbox.io/s/controlledfilters-static-filter-field-0fvyev?file=/demo.js

Ideally, we should also provide an example/way of reusing our internal filter components to support these use cases without a lot of rewriting. But after a quick validation with @alexfauquette, right now, it's not possible to reuse the components outside the Grid (maybe after #3719).

[flaviendelangle]

right now, it's not possible to reuse the components outside the Grid

Those component uses hooks to access contexts containing apiRef and the props passed to the DataGrid. They can be outside of the scope of the grid "by definition"

See #2522 for context. It's a major subject which is linked to all our discussions around plugins / headless api / etc... We might be able to support it sooner with https://github.com/mui/mui-x/issues/2522#issuecomment-912506297. But I think the filter demo should be in a custom Toolbar for the time being.

[oliviertassinari]

One step closer:

https://codesandbox.io/s/datagriddemo-material-demo-forked-fyeb80?file=/demo.tsx

@flaviendelangle raised a great point, I got tricked when I used components.Headers initially for this demo. It prevents opening the column menu. This makes me wonder, why do we even have components.Headers when we can use components.Toolbar? Should we deprecate components.Headers or rename it to something else a portal is not a header?

---

For #2522 maybe it could make sense to allow more flexibility, the same way it's done in the tabs: https://mui.com/components/tabs/#experimental-api

<TabContext value={value}>
  <Box sx={{ borderBottom: 1, borderColor: 'divider' }}>
    <TabList onChange={handleChange} aria-label="lab API tabs example">
      <Tab label="Item One" value="1" />
      <Tab label="Item Two" value="2" />
      <Tab label="Item Three" value="3" />
    </TabList>
  </Box>
  <TabPanel value="1">Item One</TabPanel>
  <TabPanel value="2">Item Two</TabPanel>
  <TabPanel value="3">Item Three</TabPanel>
</TabContext>

[flaviendelangle]

I don't have a strong reason why Headers exists in the 1st place It adds an additional depth on the DOM and just instanciate the toolbar and a portal.