Move extension host out of the workbench for process reuse

[rzhao271]

As part of #120431, we have to move the extension host out of the workbench.
Currently, the workbench is the parent of the extension host. When we do a reload, the workbench is recreated. When process reuse is enabled, the workbench PID stays the same throughout the reload, but the node environment is still taken down. Due to this cleanup, the child exit signal from the extension host is not handled, creating a zombie.
By moving the extension host out of the workbench, another longer-lived process can handle the signal instead.

@alexdima do you have any specific ideas as to how the new architecture should look?

[alexdima]

Unless there are major objections, as a first step, I would try to spawn the extension host process from the shared process and establish a pipe between the extension host process and the renderer process using nodejs API. We can then remove this nodejs usage later when we get better support for IPC inside a sandboxed renderer. Given we will pipe things directly between the extension host process and the renderer process, I don't think there will be any extra load on the shared process.

[bpasero]

@alexdima Yeah that sounds like a good strategy to get going. This would reduce the sandbox related problem to switching from a node.js IPC solution to a sandbox compatible IPC mechanism 👍

One thing I was curious when I thought about how to move the extension host: currently a lot of extension host related code lives in src/vs/workbench/api but we actually will be spawning the extension host not within a workbench context, but from shared process. Would it make sense to also think about a better place for the extension host code itself? It almost seems to be this is becoming its own layer (vs/exthost)? Obviously, all the mainThread.* things would remain in the workbench land as the implementation of the protocol.

PS: In my 1on1 with @rzhao271 yesterday we discussed to have a call with you on IPC solutions for the extension host once @deepak1556 is back from vacation (later this milestone).