🏗 Replace browserify in tests with esbuild

[rsimha]

This is another in a series of PRs that modernize our development tasks.

PR highlights:

• Replace karma-browserify with karma-esbuild for test transforms
• Replace browserify and babelify in tests with esbuild and babel
• Delete babelify, browserify, browserify-persist-fs, karma-browserify from package.json
• Necessary changes to get tests to run and pass:
  • Remove the --new_server flag and always build transforms before server start up
  • Perform esbuild transforms for JS files in one go on a unified JS test file
  • Serve a test script for test-3p.js (because Karma now serves the unified file instead of individual test files)
  • Make some ES6 modules use import instead of require
  • Replace global object with its platform-specific equivalent
  • Downconvert esbuild output to ES5 on Windows so tests can run on IE 11
• Accompanying cleanup:
  • Remove persistent Karma browserify cache (to be replaced later by one for esbuild)
  • Clean up karma.conf.js and move dynamic config to runtime-test-base.js
  • Consolidate esbuild config computation for all tasks into one helper function
  • Remove unnecessary server building logic from integration.js
  • Add missing await calls to racy test status reporting
  • Fix scripts in third_party/ that were using browserify, etc. to invoke via npx

Partial fix for #32585

[jridgewell]

I pushed a few fixes.

[samouri]

Looks great ⭐

[rsimha]

All green! Ready for full review from @jridgewell, @samouri, @erwinmombay.

[samouri]

First round of comments, stil working through the last few files

[jridgewell]

This is dependent on us using .js as the only ending token, but any change to use more advanced globby features could break that. Eg, future support for TS and changing the glob to .{js,ts}. I'd rather this be explicit about fixing esbuild generation by looking for keys with values of ['esbuild', ...].

[rsimha]

Maintaining two lists, one for which files to include in the Karma server, and one for which files to run transforms on is unnecessary, because we transform every JS file with esbuild (that was the original intent). However, I see your point that not every JS glob must end with JS. One way to deal with this is to expand all the globs before processing. Will do this.

[rsimha]

Aha, I now see why we needed two lists. There are JS files in examples/ that shouldn't be transformed. I stand corrected. I've modified the logic to expand globs, but still automatically detect which files we want to transform with esbuild and which ones we don't. Lemme know what you think.

Edit: That didn't work because expanding the globs and passing them in to Karma has bad side effects. And the previous hacky version was brilliant reverse engineering, but was very hard to read / maintain, so I'd like to avoid it if possible. What if we just make it a requirement (via a comment) that Karma globs use extension-specific tokens? So if you want 'foo/bar/**/*.{js,ts}', you must specify 'foo/bar/**/*.js', 'foo/bar/**/*.ts'. It will greatly simplify the transform logic, and we can expand it in future to perform different transforms for different extensions.

[rsimha]

@jridgewell This needs one last look from you to decide how we should handle #32891 (comment).

[samouri]

I believe we lost cache invalidation in this PR, since it is only path based. I.e. it breaks watch mode for gulp dev server. Fix incoming as part of #32744