Upgrade to TypeScript 6.0

[kevinramharak]

This PR will update TypeScript and its related dependencies towards 6.x.x. TS 6 is a intermediate step towards version 7, which has been released.
For more info about version 6 and 7, see the related typescript blogs.

It also tightens some security settings with npm packages.

NOTE: This PR upgrades the repo to use typescript 6.0 as part of its build process, it does not contain any changes or tests to check if the extension works properly with 6.0 (or 7.0).

Related docs/links:

• Announcing TypeScript 6.0
• 6.0 Migration Guide
• Announcing TypeScript 7.0 (new behaviours from 6.0)
• typescript-eslint@8.58.x supports TS 6.0

Changes:

• update typescript to ^6.0.3
• update typescrit-eslint to ^8.63.0
• sort compilerOptions in tsconfig.base.json (to make it easier to use the 6.0 and 7.0 migration guides)
• remove baseUrl, as its deprecated
• add libReplacement, as its new default will be false
• change module to preserve, as commonjs is now deprecated. this seems to be the recommended setting when "my code & bundler works, dont bother me" (see Allow --module commonjs --moduleResolution bundler microsoft/TypeScript#62320)
• change moduleResolution to bundler, as node is now deprecated. same as module.
• add noUncheckedIndexedAccess, as its new default will be true
• add types with ["node"], as its new default will be an empty array, causing build errors.
• change the existing references to be an explicit relative path, related to new defaults of baseUrl and rootPath. I think it would work fine without, but the migration guide recommends explicit paths.
• move dedent from a default import (import dedent from 'ts-dedent') to a named import (import { dedent } from 'ts-dedent'). I checked the source and it exports it both as named and the default, but the new module resolution settings broke the lint task and IDE (build still worked though, no idea why). Named imports still are a better fit as its proper ESM syntax, so its probably a good reason why it errored.

Additional changes:

• Make @vscode/vsce a local dependency instead of a global install (docs and repo). By making this an explicit local dependency, we can ensure its version and thus any allowScripts permission it requires.
• add esbuild@0.28.1 to allowScripts
• add @vscode/vsce-sign@2.0.9 to allowScripts
• add keytar@7.9 to allowScripts

These additional changes are related to allowScripts (see https://docs.npmjs.com/cli/v11/commands/npm-approve-scripts).
With the recent security fiascos (also mentioned in #217), I figure these are good changes on the end of npm. It might be because I updated my node version to the latest LTS, that these are now required by default.
Since this extension has quite some users and developers (and their code) have been target of these attacks, it would be good practice to ensure our extension repo is as secure as our tools allow it to be.

I checked these install scripts myself to ensure there are no malicious or hidden effects, and pinned them to their versions to decrease the chance of a supply chain attack.

[kevinramharak]

@yoavbls Can you take a look at this and try build locally. Its main effort is to update to TS 6.0, which should make the migration to 7.0 easier.
I ran into the npm security stuff because I think npm has made some changes after the recent supply chain attacks, and I couldn't build on my environment without fixing it. That is why its part of this PR instead of seperate. I thought it would be a good idea to fix it anyways, because of the large amount of users of this extension has and that some of the recent attacks were targeting vscode extensions.