Repository: angular
Issue: Internal repo tooling: use ESLint instead of the deprecated TSLint
Labels: area: dev-infra

### Which @angular/* package(s) are relevant/related to the feature request?

core

### Description

Apologizes for using the wrong issue template here: this is a **tooling** suggestion for this repository itself, _not an end-user-facing_ request. I [asked on the Angular Discord](https://discord.com/channels/748677963142135818/749140853921939507/1254227088756576289) where to post and this was the best guess.

Angular uses [TSLint](https://palantir.github.io/tslint) for its internal linting ([`tslint.json`](https://github.com/angular/angular/blob/49b2e65bfb097b25da09870ca8a07650812e3d68/tslint.json)) right now, although [TSLint was deprecated years ago](https://github.com/palantir/tslint/issues/4534). TSLint doesn't support all new TypeScript features and hasn't been actively worked on since 2020. Its replacement is [ESLint](https://eslint.org) with [typescript-eslint](https://typescript-eslint.io).

Some related issues & PRs from searching [`tslint in:title`](https://github.com/angular/angular/issues?q=tslint+in%3Atitle):
* #37843 -> https://github.com/angular/angular-cli/issues/13732: user-facing, not the same as this one
* #42639: user-facing, not the same as this one
* #42820: only part of the way

### Proposed solution

I propose incrementally switching over to ESLint. One common strategy many repositories go with is:

1. Add ESLint separately from TSLint, integrated into the same build processes
    * Tip: https://github.com/angular-eslint/angular-eslint
3. Remove old _built-in_ rules from the TSLint config and replace them with their new ESLint equivalents
    * Tip: https://github.com/typescript-eslint/tslint-to-eslint-config is the standard helper there
4. Remove old _custom_ and _plugin_ rules from the TSLint config and rewrite and/or replace them with new custom and/or plugin equivalents
    * Tip: for anything that can be generalized, this is a great time for adding a new or existing `eslint-plugin-*` package!
5. Once there are no more TSLint rules in use, remove it altogether

I'd be happy to help with this! "Killing TSLint" is IMO helpful for the ecosystem: both to get projects on the latest+greatest tooling, and to help get more community input into ESLint + typescript-eslint.

### Alternatives considered

I suppose Angular could stay on TSLint in perpetuity, which would be a real bummer. Or even fork the old TSLint codebase - structural issues and all.

Another alternative would be a linter besides ESLint. There are some Rust-based ones such as [Biome](https://biomejs.dev), [`deno lint`](https://docs.deno.com/runtime/manual/tools/linter), and [Oxc / `oxlint`](https://oxc.rs/docs/guide/usage/linter.html) - though none yet support [linting with type information](https://typescript-eslint.io/getting-started/typed-linting) yet. Alternately, [tsslint](https://github.com/johnsoncodehk/tsslint) is also in development, though it's not clear that it's quite the same maturity yet as the others.

My understanding is that Google still uses TSLint internally, and having this public angular/angular repo also use TSLint has some nice benefits for tooling. It'd be great to know if that's the case, and if so, whether an initiative to migrate the tooling over to a newer tool would be desirable + feasible.