feat(linter): PoC to enable type-aware linting via the .oxlintrc.json file

[connorshea]

Part of #15972.

Built from the guts of #16583 (basically the same PR as that one, but the refactors over the last few weeks made rebasing too difficult so I copied most of the changes over manually).

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"
  }
}

---

How this works currently:

• You can set typeAware: true in the oxlintrc.json file to get type-aware linting without needing the --type-aware flag.
• This works with the LSP (still need to manually test that, but I'm pretty sure it does).
• If any nested configs enable type-aware linting, we enable it for everything, even if the base config or other configs set it to false.
• If all configs have typeAware: false or have it unset, it will not be enabled.
• Passing the --type-aware CLI flag overrides typeAware: false in the config, and type-aware linting is enabled.
• Passing the LSP config setting for typeAware linting overrides typeAware: false in the oxlint config, and type-aware linting is enabled.

So, the major problem that is still remaining is full nested config support. We either need to:

• Drop support for setting the typeAware setting in nested configs.
• Or we need to update the logic for what paths we send to tsgolint, by determining the paths based on the nearest nested config and its typeAware setting.

The latter is outside my current ability level with Rust, frankly, so I'll need someone else to tackle that part assuming we want to do it, which we maybe should? I'm still a bit hesitant.

(Alternatively, I guess another option is to ship the current behavior, where any config - nested or base - enabling type-aware linting means all configs enable type-aware linting, but I don't love that behavior).

And here's an example of current behavior working correctly :)

connor@mac oxlint-test % node ../oxc/apps/oxlint/dist/cli.js 

  × typescript-eslint(no-misused-spread): Using the spread operator on a string can mishandle special characters, as can `.split("")`.
  │ '- `...` produces Unicode code points, which will decompose complex emojis into individual emojis- .split("") produces UTF-16 code units, which breaks rich characters in many languagesConsider using `Intl.Segmenter` for locale-aware string decomposition.Otherwise, if you don't need to preserve emojis or other non-Ascii characters, disable this lint rule on this line or configure the 'allow'
  │ rule option.
   ╭─[src/index.ts:4:35]
 3 │ // This will ONLY error if the typeAware linter option is working.
 4 │ const typeAwareViolationString = [...typeAwareViolation];
   ·                                   ─────────────────────
 5 │ 
   ╰────

Found 0 warnings and 1 error.
Finished in 129ms on 3 files with 1 rules using 8 threads.
connor@mac oxlint-test % cat .oxlintrc.json                  
{
  "linterOptions": { "typeAware": true },
  "plugins": ["typescript"],
  "categories": { "correctness": "off" },
  "rules": {
    // This rule will only be enabled if the typeAware linter option works :)
    "typescript/no-misused-spread": "error",
  }
}

(note that the output of this rule is busted, see oxc-project/tsgolint#595)

[codspeed-hq]

Merging this PR will not alter performance

✅ 4 untouched benchmarks
⏩ 41 skipped benchmarks¹

---

_{Comparing type-aware-config (72f0cec) with main (7a0ca99)²}

Footnotes

1. 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. ↩

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

[connorshea]

This same file is copied a few times with different names for different test cases because I can't (or couldn't figure out how to) pass anything into the snapshot tool to add further context, so the only thing that helps distinguish the snapshots and what they're intended to show is the name of the file being linted.

Can probably improve this somehow.