Use prettier CLI + pretty-quick

[Janpot]

Avoid too much drift with prettier CLI. Let's see how well this works for us (pretty-quick feels a bit faster)

[render]

Your Render PR Server URL is https://toolpad-pr-823.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-cbv4gj9gp3jq1o8rk74g.

[oliviertassinari]

If it works well, could we replicate the change to mui/material-ui? I think that this mono-repository should be our source of truth for tooling. This would avoid us to have to find how to fix the same bugs in two different ways, as well as help to better stress test the solutions (faster feedback loop).

[Janpot]

Giving it a try here: mui/material-ui#34062

pretty-quick seems to be about 300ms faster for some reason:

yarn run v1.22.19
$ pretty-quick --ignore-path .eslintignore
🔍  Finding changed files since git revision df891841e9.
🎯  Found 4 changed files.
✅  Everything is awesome!
✨  Done in 0.84s.

vs

yarn run v1.22.19
$ node ./scripts/prettier.js
✨  Done in 1.11s.

The only problem I ran into is the handling of translations: https://github.com/mui/material-ui/blob/df891841e991a4c5e84cd20b79352b18b04fba84/scripts/prettier.js#L64-L67
It seems like we don't enforce any formatting on files coming from crowdin. prettier finds 85 translated files with formatting problems. e.g. there's the codeblock containing purple. A200;. It seems to me it would be better to enforce correct formatting in crowdin (maybe we can block merging these translations if prettier fails?).

Also had this PR open already to fix the yml handling of the current solution mui/material-ui#33980. It was not the first time that I noticed the script has drifted from prettier capabilities, which is the reason why I suggested replacing it with the prettier CLI.