Make ParentProcessWatcher optional

[ralish]

The ParentProcessWatcher functionality is extremely inefficient in some scenarios. For example, when we're running on Windows under VS Code as launched by Red Hat's VS Code XML extension a separate instance of the lsp4xml language server will be launched per tab where the extension is loaded. Each of these tabs will independently start checking if the parent process which launched the LSP (Code.exe) has exited after the idle period. Note the idle period is simply calculated as >30 seconds since a message was last received from the client, so this tends to be reached quickly.

Each check for if the parent process has exited will typically spawn four unique short-lived processes: cmd.exe, conhost.exe, tasklist.exe, and findstr.exe. This is multiplied by the number of instances of the LSP which are running. Somewhat ironically, the entire check is actually unnecessary in this scenario as the LSP is launched by VS Code as part of a Windows Job object which guarantees that if it exits the child processes it spawns will be terminated with it.

I propose a flag which can be passed to the LSP on startup to disable the parent process watcher when it's being run in an environment that will handle its termination. There's separately scope for improving the underlying ParentProcessWatcher implementation for when it is required but that should be addressed in a separate issue.

[fbricon]

I agree, the parent process watcher is extremely inefficient, specially on windows. It actually comes from Eclipse jdt.ls, where, in the past, we were seeing zombie java processes surviving killed VS Code instances. It seems things might have improved now, and we might be able to get rid of it. At the very least, make it optional. I suspect we might still need it in some circumstances, in which cases we should find a more optimal solution.