Latest runs integration test off esbuild output 🎉

Ready to merge, this is much less risky then initially as the old tsc-based webpacked output is still shipped, just the ESM output is based on esbuild.

@Tyriar Wow, this looks like some heavy lifting to get ESM rolling, thx for doing the nasty works! 🚀

This diagram looks important to me - should we link that under the wiki build page? Also to make sense for me - does that mean, that internally all packages are still handled by UMD, but the final packages for delivery are ESM now? Or do we ship now UMD and ESM in the final packages?

@jerch yeah it was a bit rough, but a lot of this felt necessary in order to bring the nice scroll bars over.

This diagram looks important to me - should we link that under the wiki build page?

Good idea, I'll clean up the diagram and stick it in contributing.md and/or the wiki.

Also to make sense for me - does that mean, that internally all packages are still handled by UMD, but the final packages for delivery are ESM now? Or do we ship now UMD and ESM in the final packages?

We ship both which is possible by using the main and module properties in the package.json. Internally all packages use the esbuild sources and webpack is not touched at all until yarn package happens which is where the big perf wins come from as we don't need to wait for webpack to bundle after a change happens.

I wanted tsc to use noEmit such that we could remove out/ and then remove -esbuild from those folders completely to simplify things, but in order to use project references ("composite": true and "references": {...}) we must emit the output. esbuild by itself doesn't verify types but instead just strips them out so we must run it.

Did a full rewrite of the contributing page https://github.com/xtermjs/xterm.js/wiki/Contributing and added image source to the repo in #5094