Revisit CesiumJS build tooling

[ggetz]

Main motivations behind taking a more modern approach to the build process:

• Bundling modules by default to improve loading performance in the browser. It's likely that this will workaround CesiumJS at least partially broken in latest Chrome on Linux #9416 which is caused by the sheer number of individual modules when we run a Cesium app.
• Avoid manually copying over third-party dependencies
• Preprocessing will allow us to use ES6+ language features more freely without sacrificing browser support

Factoring in community feedback and our own research, we plan on using esbuild to build, due to

• Speed, which is crucial for decreasing developer friction when re-building after changes have been made
• Relatively minimal configuration when compared with tools like webpack, which we've run into some fragility with in the past (for instance nodeRequire is not a function #7669), and vite (which uses esbuild under the hood). We won't be able to make much use out of the extra features these tools offer, such as hot module reloading.
• TypeScript support if we chose to go that direction
• Our experience using esbuild internally in other projects

As part of this, we'll want to:

• bundle Cesium.js
  • Remove buildThirdParty from the build task, and instead include npm modules directly, as we do in ThirdParty/npm
  • Can we further simplify the glsl to js build step?
• Build the Workers as separate entry points
  • Remove requirejs from cesiumWorkerBootstrapper and use importScripts directly (which I think is one of the last actionable items in Replace third party libraries with npm modules #9473)
• Add a watch task to rebuild when code changes are made (make use of caching to build incrementally?).
  • I'm thinking we'd also want to break down the build talk into ints components and only re-build workers, shaders, or source depending on what changes.
• replace rollup+terser to bundle for release and minify, including copyright header as a banner
• Strip code between debug pragmas... We may need to write our own plugin (similar to strip-pragma-loader for webpack)
• Source maps- Generate Source Maps #8245 - can be generated with esbuild, but we should be certain that when we strip out any debug pragma code that it gets factor into the source maps
• Make sure our build scripts are at the right granularity, as well as named descriptively and consistently
• Consider the build process for apps and tests, as well as what output gets packaged in the release - CC Revisit release packaging #8343
  • Double check performance for focused specs - Add updated browser spec runner #10293 (comment)
• Do we build separately for node to fix issues such as Regression: sampleTerrain no longer works in NodeJS #9906?

Am I missing anything crucial?

I started a prototype in the build branch and building and bundling are already much faster.