ci: Fix eslint integration

[vogelsgesang]

In #363, I accidentally disabled all eslint checks: I used eslint and thought this would actually run the linter on the complete source tree. Starting from ESLint 9.0, this will actually work (See https://eslint.org/blog/2024/04/eslint-v9.0.0-released/#running-eslint-with-no-file-arguments). But for ESLint 8.x, we still need to use eslint .

This commit fixes that oversight in package.json and rectifies all the fall-out from this mistake.

First, I finished the migration to the new eslint.config.js format. To avoid further bugs, I first enabled TypeScript's type checking via @ts-check. I then followed the migration guide from https://eslint.org/docs/latest/use/configure/migration-guide to fix the config in general.

Doing so, I changed a the linter config in the following way:

• I disabled the max-classes-per-file linter rule. My change refactor: Simpler and more type-safe BazelTaskInfo #365 violated this rule. But I don't think that this rule provides much value in general. Having one class per file is rather a Java convention than a JavaScript convention...
• I replaced prefer-arrow/prefer-arrow-functions by the built-in prefer-arrow-callback. Afaict, those checks do the same. This allowed me to remove the dependency on the package eslint-plugin-prefer-arrow.
• The linting actually alos applied to the eslint.config.js file itself. But not all packages have types, zet. I hence disabled a couple of rules for this file.

With that out-of-the way, I had to fix the actual lint warnings:

• In `eslint-plugin-prefer-arrow bazel_workspace_info.ts and buildifier.ts: "Unexpected lexical declaration in case block"
• extension.ts had an (intentionally) dangling promise
• debug-adapter/connection.ts had an intentional while(true) loop.