Build Theia as ESM modules

[tsmaeder]

Feature Description:

Currently, Theia is published to npm as a bunch of CommonJS modules. This works fine, but might start to have disadvantages in the future:

1. We use the ESM build of VS Code for the monaco editor, but consume it as CJS modules: forcing the module type to ESM breaks our uses of vscode stuff in our tests. Since we currently use Webpack for the back end also, the productive build seems to work. However, we need to patch some files in the ESM VS Code build that use the export keyword to use the CJS export convention
2. More and more published modules switch to ESM-only format: in order to use such modules from CJS modules, we'd have to use the async require function. Webpack can alleviate this problem, unless the modules use "top level async" functionality.
3. We can't properly tree-shake CJS modules. We could probably expect our artifacts to be around 30% smaller if we could. With our front end artifacts clocking in at around 10mb, using optimized ESM modules might make startup quite a bit faster on slowish connections.

[tsmaeder]

@sdirix, @msujew , @JonasHelming and @tsmaeder had a discussion about this and here's a couple of results:

• Moving to ESM would be a breaking change for our adopters: not only would they have to fix their build, but you have to explicitly export symbols from your package, many symbols which are exported now would become private. On the other hand, this would give us more control over what we consider API.
• Offering both a ESM and CommonJS build of Theia is probably unfeasible: if we start using VS Code as a real ESM build mixing the module formats does not make sense.
• Since we can "fix" the VS Code build to work as a CJS modules, we are under no immediate pressure to move to ESM. It's a bit more work for each monaco uplift, but probably doable.

Overall, we decided moving to ESM is a mid-term project that needs more consideration before implementation.