cleanup dependencies

[kevinramharak]

This PR is a cleanup based on #142

changes:

• "@types/node": "^16.11.68" because the vscode engine we are targeting (^1.77.0) uses node 16.14.2. The closest version to match it with @types/node is 16.11.x. This should keep the extension code to whatever API is available in that version.
• "@types/vscode": "^1.77.0", should match our targeted vscode engine
• removed eslint related things from apps/vscode-extension, its still part of the root package.json
• remove obsolete @types/eslint__js
• remove mocha, glob, path-browserify from root package, as they are part from specific packages that use them.
• add node >= 20 to `engines field in root package.json, before the merge this was present. This should help in indicating node >= 20 is needed to build & develop the project without issues
• fixing the packages somehow fixed eslint in my vscode to start working, so I fixed the missing globals package to make it stop complaining.
• removed nodeDepsPlugin, as path is not actually used, thus no need to resolve to a polyfill

@yoavbls I tried to keep this minimal to only update non breaking stuff, but I'm not sure about how to structure packages in a mono repo.
Right now the root has:

• prettier for formatting
• eslint for linting (not enabled with any script right now)
• typescript
• turbo
  And each package itself has devDepencies to build itself and runtime dependencies that it uses at runtime.

[yoavbls]

Thank you Kevin!
about eslint - I wanted to leave it as simple as possible, so right now it is defined on the root and only works in the IDE I guess

about turbo repo - TBH I'm not sure we need it, right now we're not using it for anything helpful so we can remove it too

[kevinramharak]

@yoavbls I'm working on a different extension (Regex Radar), where I pretty much copied most of the structure from here, as it works really well as a monorepo for extensions.
That one has a server, client, and lsp-types to implement the LSP server/client and types.
Being able to run turbo run dev is very convenient, so I think we can keep it for when implementing the language server as a separate package.

[yoavbls]

Cool, so we'll keep it