[DevTools] remove backend dependency from the global hook

[mondaychen]

Summary

• [DevTools] Remove renderer.js from extension build #26234 is reverted and replaced with a better approach
• introduce a new global devtools variable to decouple the global hook's dependency on backend/console.js, and add it to react-devtools-inline and react-devtools-standalone

With backend dependency removed from the global hook, we make sure it will work with different versions of devtools backends in the future.

With this PR, I also want to introduce a new principle to hook.js: we should always be alert when editing this file and avoid importing from other files.
In the past, we try to inline a lot of the implementation because we use .toString() to inject this function from the extension (we still have some old comments left). Although it is no longer inlined that way, it has became now more important to keep it clean because 1) it is a de facto global API people are using (9.9K files contains it on Github search as of today); 2) it needs to be compatible with any version of devtools backends we will create in the future.

File size change for extension:
Before:
379K installHook.js

After:
21K installHook.js
363K renderer.js

[tyao1]

Is the goal that we can later inject different backend versions?

[tyao1]

Changes look good!

[tyao1]

What could error before and why are we removing the catch?

[mondaychen]

That's a great question! In the original implementation, the hook is injected into the page via an inline script tag with installHook.toString() as the content. For example:

react/packages/react-devtools-extensions/src/injectGlobalHook.js

Lines 92 to 98 in 2b903da

	injectCode(
	';(' +
	installHook.toString() +
	'(window))' +
	saveNativeValues +
	detectReact,
	);

Because webpack will add some prefix (like _backend_console__WEBPACK_IMPORTED_MODULE_0__) to the modules imported in hook.js during compiling, it would actually always cause an error in the extension. This try-catch is for that purpose.
The comments on the top of hook.js says "we have to inline the whole ... implementation here" for the same reason.
Now we are using a much more elegant way to inject the hook, this is no longer necessary.

[mondaychen]

People probably wanted to patch as early as possible for all platforms. But they didn't find a way to make it work for the extension. Then they noticed that the DevTools backend is initialized automatically by the extension, so it was accepted to patch it a bit later.

[mondaychen]

This patched console depends on WorkTagMap, which is defined in the reconciler and can be changed in different versions. Going forward I think it's the best to keep it with the devtools backend. On dev and profiling builds we will be able to patch it early even on the web. On prod builds it should be OK to not have this additional information before the DevTools backend is initialized.

I'd like to hear thoughts from @gaearon and @acdlite, if any

[mondaychen]

Is the goal that we can later inject different backend versions?

Yes!