feat(linter): Add linterOptions.typeAware

[connorshea]

Built with help from GitHub Copilot + Raptor mini (GitHub's preview model).

Part of #15972.

This allows setting the typeAware option in the config file. It is nested under the new top-level linterOptions field. The name was chosen as it's the one used by ESLint and will also hold things like the reportUnusedDisableDirectives setting in the future.

The goal of this to allow teams to set this in the config file, and that'll help ensure that everyone on a project is using the same linter rules. Otherwise, when I adopt this at work (hopefully in the near-ish future) I will need to have every dev on the team do unnecessary manual configuration.

Without this, everyone would need to configure their editor settings to enable type-aware lint rules and also ensure that they're running oxlint with the right command if they use it via the CLI.

My hope is that more linter options will be added under linterOptions in the near-ish future to enable more consistency like this, but this seemed like one of the more important options to add directly to the config file.

Examples:

{
  "linterOptions": {
    "typeAware": false
  },
  "rules": {
    /// Even though it's set to `error,` this is NOT run because it is a type-aware rule and we have `typeAware: false`.
    "typescript/no-floating-promises": "error"
  }
}

{
  "linterOptions": {
    "typeAware": true
  },
  "rules": {
    /// This is a type-aware rule and will be run because `typeAware` is true in linterOptions.
    "typescript/no-floating-promises": "error"
  }
}

TODO:

• This should inform whether type-aware rules are enabled in the LSP/VS Code extension. If the user has not set a setting to specifically override the
• Maybe mention this config option in the --type-aware flag docs.
• May want to prevent this from being set in a nested config? Currently it doesn't error, but I'm also unsure if it actually works or not in a nested config.
• Should LintConfig have a linter_options field at all, is that what determines the available options for a nested config file? Or should it be excluded like categories are?
• Should we add a --disable-type-aware flag to disable the behavior, for the case where the config has typeAware: true?

Note that I gave type_aware the type Option<bool> because I intended to make it not effect nested config files, we can undo that if we want it to work for nested config files.

[codspeed-hq]

CodSpeed Performance Report

Merging #16583 will not alter performance

_{Comparing type-aware-config-file-opt (4e365e9) with main (fef77af)¹}

Summary

✅ 4 untouched
⏩ 41 skipped²

Footnotes

1. No successful run was found on main (1149b6a) during the generation of this report, so fef77af was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 41 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Sysix]

Note that I gave type_aware the type Option because I intended to make it not effect nested config files, we can undo that if we want it to work for nested config files.

Nested Configs are the default. For me, it would be strange to only support it in the root config.
Example: Team X owns packages/package-X and they want to test type aware.
Team Y does not want type aware.
The extends should cover project wide configurations.

The Language server part should be here:

oxc/crates/oxc_language_server/src/linter/server_linter.rs

Line 126 in 913b1b3

type_aware: options.type_aware,