[Feature]: Support type-aware rules for community ESLint plugins (expose parserServices / getTypeChecker())

[fansenze]

Summary

rslint runs community ESLint plugins, but only their non-type-aware rules. Any rule that reads sourceCode.parserServices (program / getTypeChecker() / esTreeNodeToTSNodeMap) loads but silently never reports — parserServices is handed over as an empty {} (source-code.ts:616). The ESLint plugin guide already lists this as a known limitation.

Why this matters

The built-in @typescript-eslint plugin (array form plugins: ['@typescript-eslint']) is re-implemented in Go and is type-aware. But a community plugin mounted in object form (plugins: { foo: fooPlugin }) only gets the JS surface — so type-aware @typescript-eslint rules rslint hasn't natively ported can't be recovered by mounting the real plugin, and third-party type-aware plugins can't run at all. It's the biggest remaining gap in community-plugin compatibility.

Expected behavior

• When languageOptions.parserOptions.project is set, a type-aware rule from an object-form community plugin sees a working parserServices instead of an empty {}.
• It produces the same diagnostics under rslint as under stock ESLint + @typescript-eslint.
• Consistent across the CLI and the VS Code extension.