refactor: Move react-jsx-development implementation into react-jsx

[nicolo-ribaudo]

Q	A
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

While working on #12493, I was quite annoyed that I had to use some Object.defineProperty hacks to avoid breaking internal backward compatibility, since the JSX implementation was split across different packages.

Thus, I started looking into our JSX transformer to see if that could be "fixed", and this is what I found:

1. @babel/plugin-transform-react-jsx and @babel/plugin-transform-react-jsx-developement had the exact same code, except for three lines out of 60: https://www.diffchecker.com/VMLlhaGz.
   The first commit in this PR moves the development implementation into @babel/plugin-transform-react-jsx, to deduplicate all this logic. In the next minor, we can decide to expose it as @babel/plugin-transform-react-jsx/development so that users don't have to install two packages.
2. After doing (1), @babel/plugin-transform-react-jsx is the only package depending on @babel/helper-builder-react-jsx-experimental. This is done in the second commit.
   There is @babel/plugin-transform-react-inline-elements that still depends on @babel/helper-builder-react-jsx, but I asked to the React team and it turns out that the inline-elements helper is not needed with modern React versions because it doesn't give performance benefits. We probably won't need to update it anymore, so it can continue using the "non experimental" JSX builder.
3. All the other commits refactor a big the JSX builder, to remove some duplicated code, remove some unused code, and make it a bit easier to follow what's going on. The net result is that this PR deletes 270 lines of code.

I suggest reviewing this PR in two steps:

1. First, the Move react-jsx-development implementation into react-jsx commit (the first one) which is self-contained.
2. Then, all the other commits together by opening https://github.com/nicolo-ribaudo/babel/blob/remove-jsx-experimental-helper/packages/babel-plugin-transform-react-jsx/src/create-plugin.js (my branch) on one side and https://github.com/babel/babel/blob/main/packages/babel-helper-builder-react-jsx-experimental/src/index.js (main) on the other. You can review it function by function, since I didn't delete any of them and the only ones I added are function call and function getTag.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit c574765:

Sandbox	Source
babel-repl-custom-plugin	Configuration
babel-plugin-multi-config	Configuration

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/35709/

[hzoo]

Nice win! I guess I wonder if the reason why it was initially 2 packages was just for ease of deploying it and not wanting to add to much extra logic to the first version @lunaruan? But now if we are removing the old package anyway we can just merge the 2 modes?

[nicolo-ribaudo]

The reason for having a separate package was to make the split between the two modes explicit (rather than just using an option): #11154 (comment)

This PR still keeps the split from the user's point of view, and I just moved the implementation.
The reason I'm suggesting that we could introduce @babel/plugin-transform-react-jsx/development (and not a development: true option) is to maintain this clear distinction.

[Andarist]

A good refactor 🚀

I'm just overall not super sold on the development one being a separate plugin (even if it lives in the same package). I don't quite see what problems does this solve - and due to issues with plugins merging this can accidentally make the JSX plugin be used more than once which results in often very hard to debug runtime errors (although in this regard it's somewhat a stretch because it's rather hard to include both dev and non-dev JSX plugins on the very same plugins list)

[nicolo-ribaudo]

this can accidentally make the JSX plugin be used more than once

One of my next PRs to our JSX plugins will be warning when two of them are enabled. This does not prevent the problem, but at least makes it obvious.