[code-infra] Fix type resolution for @mui/types

[Janpot]

On a project that depends on @mui/material, when running tsc with the --traceResolution flag I can see that for moduleResolution: 'node' it prints

======== Module name '@mui/types' was successfully resolved to '/Users/janpotoms/Downloads/nbwiykrajq.github/node_modules/.pnpm/@[email protected]_@[email protected]/node_modules/@mui/types/index.d.ts' with Package ID '@mui/types/[email protected]+@types/[email protected]'. ========

and for moduleResolution: 'bundler' it prints

======== Module name '@mui/types' was not resolved. ========

Looking at the @mui/types package, it's indeed not a proper dual mode package, I'm aligning it with our other packages to get correctly resolving types.

Confirmed that this fixes #45510

[mui-bot]

Netlify deploy preview

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

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against c6c9162

[DiegoAndai]

Thanks for working on this fix @Janpot!

1. Just to check that I understand this correctly: This seemed to start on 7.0.0-beta.3 but actually, it started on @mui/types 7.2.23 as we used the new package layout but the package wasn't ready for it, right?
2. What should we do with versioning? Should this bump the major on @mui/types? It would become 8.0.0. I don't know the reason this package is versioned differently from the others.

[Janpot]

@DiegoAndai The package was built differently than the others and it suddenly got an exports field without having the correct files. For some reason it's not bumped with the major version, I didn't realize, but really, this should follow the major version. I believe we could do the following:

1. Merge and publish this PR asap as 7.2.24.
2. For v6 dependencies, let's tighten its range to be <7.3
3. for v7 publish to 7.3.0, then just let it follow major versions from then on