@rjsf/material-ui breaks tree shaking

Prerequisites

• I have read the documentation;
• In the case of a bug report, I understand that providing a SSCCE example is tremendously useful to the maintainers.
• Ideally, I’m providing a sample JSFiddle or a shared playground link demonstrating the issue.

Description

Importing @rjsf/material-ui into a project bundled with esbuild causes bundle size to increase a lot.

This seems to be because of https://github.com/rjsf-team/react-jsonschema-form/blob/master/packages/material-ui/src/Theme5/Mui5Context.tsx#L11, which causes the entire @mui/icons-material package to be included in the bundle.

Bundle size with @rjsf/material-ui included: 6,9M Bundle size without @rjsf/material-ui: 2,4M

Steps to Reproduce

1. Include @rjsf/material-ui in a project
2. Bundle it using a tree-shaking enabled bundler (like esbuild)
3. Compare bundle sizes before and after @rjsf/material-ui inclusion

Expected behavior

The icons should be tree-shaken and only icons used by the application should be included in the bundle.

Actual behavior

All icons from the @mui/icons-material package are included in the bundle.

Version

        "@rjsf/core": "^4.0.1",
        "@rjsf/material-ui": "^4.0.1",

[heath-freenome]

@rollercodester @mdarocha I may try to meld the two approaches when I have time this weekend… Get a better approach to type handling that is highlighted in the PR by @rollercodester along with trying the /*#__PURE__*/ directive to get tree-shaking

[rollercodester]

I spent a little more time on this after remembering that the MUI project is structured so that each component can be required on its own. This negates the need for code-splitting, rather each component just needs to be required individually.

I took a stab at another PR (#2754), making sure that all of the components are individually required and also properly typed (i.e. no more use of any). Additionally, I abstracted context usage into a hook so that the component consumption is much easier to maintain in the future.

I’ve verified that this results in a 68% (6.34mb) reduction in the resulting parsed bundle. The previous (yucky) PR has been closed in lieu of #2754.

@heath-freenome, feel free to ignore if you still want to dig in this weekend. I did this mainly to ease my own sanity as it was bugging me.