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

## 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](https://rslint.rs/guide/eslint-plugins) 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.