optim(watch): don't reset `DocumentRegistry` b/t watch cycles

Summary

Keep the DocumentRegistry b/t watch cycles instead of resetting it

Follow-up to my findings in #386, 3. specifically
Potential fix for the OOM in #177, but difficult to tell since there's no repro and it's coming from TS itself

we can re-use the same one during watch instead of resetting it in the options hook
- should make the LS a bit faster / more efficient in watch mode as most source files are shared between watch cycles

DocumentRegistry can actually be shared between multiple LSes for #177. Per the TS LS Wiki, sharing DocumentRegistry is actually recommended, as, minimally, lib.d.ts could be shared between projects.
- But to do that we'd probably have to expose an option for it and users would have to opt-in. On second thought, this might not even be useful for #177 since those are separate processes that don't share variables 😕
  - Thinking about it one step further... we could actually create the DocumentRegistry as a top-level var, before the plugin is instantiated... that would make DocumentRegistry shared between all imports of rpt2... but it would still be limited to only the same Node process... so guess that's probably not useful either in this case 😕
    - And the top-level instantiation could be a bit hacky since tsModule isn't set till plugin instantiation (as visible in this PR, where the DocumentRegistry is only instantiated after tsModule is set)...
  - Leaving it as is here, as a result then
It's possible we can avoid recreating the LS itself between watch cycles. That would be optimal. I believe we'd be able to do that if the parsedConfig hasn't changed between watch cycles, which is probably the most common usage of watch anyway, i.e. changing source files and not config