Support a file blacklist in tsserver configuration options

My scenario is this: suppose I'm working in my editor, and I open a file which, by chance, crashes the language service. Repeatedly. (usually because of it's size or shape). Today, after the service crashes 5 times in short order, the service is disabled by the editor (which if it crashes on load, is what will occur). What I propose is this; if the service crashes after a file open request is issued, and we would shut down the service, instead we automatically add the file to a workspace-local tsserver blacklist config (probably in .vscode/settings.json) and reload the language service with the new option. The language service will then refuse to actually load the blacklisted file contents, instead reporting them as empty files/empty modules/empty json documents and potentially issue a warning-type error message in the diagnostics that certain files are blacklisted, which may affect the compilation.

cc @mjbvz do you think this'd be a good idea for a slightly more progressive degradation of experience when the language service has trouble with a file?

Start by tracing tsserver handling of file-open requests and the configuration options used by the language service. Review how workspace-local .vscode/settings.json could represent a blacklist and how reloads occur after repeated crashes. Done means a blacklisted file is safely treated as empty, diagnostics can warn about the effect, and the service remains available instead of being disabled.