[material-ui] Refactor ComponentsVariants type into a generic

[blakenetz]

Refactored ComponentsVariants type to accept a Theme parameter. Doing so makes the ComponentsVariants type share the same signature as the generic ComponentsOverrides type. Since both types are used when overriding a component's style, the callback functions should be identical.

The primary use case is for consumers, like myself, who use a custom Theme interface. We do this through augmenting the createTheme module, which works fine, except for this one instance. The current implementation type-checks the theme parameter correctly in the styleOverrides property, but not in the variants property. Here is an example that might better explain this:

styleOverrides: {
   // Here `theme` is typecasted by the argument passed to the Components interface  
   root: ({ theme }) => { ... },
},
variants: [{
   props: { ... },
   // but here the `theme` is always `Theme`
   styles: ({ theme }) => { ... },
}]

I should also note that the ComponentsVariants and ComponentsOverrides types are only used in the Components interface (also a generic with a Theme param), so this is a low-risk change imho.

• I have followed (at least) the PR section of the contributing guide.

[mui-bot]

Netlify deploy preview

https://deploy-preview-39623--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against e3beef9

[blake-discover]

@mnajdova, @mj12albert
Is there anything y'all need from me to move this PR forward? Anything I can expand on or clarify?