Refactor build scripts and npm package process

[etrepum]

Addresses refactoring of npm/build processes per #5869

• [x] Adds some tests to sanity check packages (their package.json, the existence of flow and docs)
• [x] Refactors basically all of scripts/* to use a generated model for the available packages
• [x] Update scripts/www/rewriteImports.js to use the new infrastructure
• [x] Generate tsconfig.json paths (npm run update-tsconfig)
• [x] Generate .flowconfig paths (npm run update-flowconfig)
• [x] Generate boilerplate README.md and docs/packages/{package}.md files (npm run update-docs)
• [x] jest config
• [x] viteModuleResolution
• [x] docusaurus config
• [x] Started a Maintainers' Guide section in the docs (currently fairly hidden, only referenced in the repo README)
• [x] Adds build integration tests to make sure all of the examples and several other framework scenarios (astro, svelte, next.js) build and run with release artifacts

RE #5869 this mostly addresses the "Reduce number of changes needed to add new package" - since I have not added a new package myself yet I think another maintainer (@StyleT?) could add those docs to the guide using this as a baseline?

I was also thinking about maybe starting on an eslint plugin in the next week or two to help with the "rules of $functions" so if someone else doesn't get to it first I could add that documentation then when I am more familiar with all of those details.

Closes #5940 (parts of this PR were extracted there to maybe expedite review)

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 24, 2024 10:51pm
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 24, 2024 10:51pm

[etrepum]

@StyleT I wanted to put this up earlier on in case you had any feedback on this approach. Probably just look at the last commit, the rest of them are from the other PRs.

[etrepum]

@StyleT

1. In a way, the maintainers guide is documentation about the tools that this PR either updates or adds. I could add that file separately, but I'm not sure what the point would be. I could certainly split up the work into multiple commits, e.g. "all of the tools" and "automated modifications to configuration" could be separate, but otherwise this is all rather intertwined.
2. The primary reason I chose to put it in lexical-website was that the CONTRIBUTING.md isn't rendered anywhere on lexical.dev, and the intended audience for this document are people working a lot closer to the build infrastructure than almost all contributors would need to worry about. It seemed like a better idea to keep CONTRIBUTING.md short so it's not intimidating.
3. Per creating a new module, that I would either like someone else to work on, or I will handle that separately in the course of creating a new module. I haven't added a new module yet, so I am not confident that I have all of the required steps in order, especially things that are outside of the source tree like the PR template and other meta concerns. There is some commentary about that in the description of this PR.

[etrepum]

happy to rebase and fix conflicts on this one when someone gives me a heads-up (on here or discord) that they're ready to review and consider for merge, I don't want to have to do it too many times (edit: merged with main on 2024-04-17 to sync up with v0.14.5)

[acywatson]

This looks good to me - huge improvement.

I honestly don't know if all the WWW and flow stuff is right, but I think the fastest way to tell is to merge and fix any issues that come up in the sync.

I'll run a sync internally ASAP, then we can merge this and do a sync with just this PR so we can catch any issues.