Migrate pylint to ruff
Hi @mroeschke, while looking into the `pylint` rule, I noticed that most of them are currently gated behind the `preview` flag. Do you think we should enable the `preview` flag or wait some rules to be promoted to stable in `ruff==0.2.0` (should be released in the next few weeks)

Other than that, this PR is ready for review.

- [ ] closes #xxxx (Replace xxxx with the GitHub issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Is it possible to opt in to preview mode with just pylint? @mroeschke can you take a look at the latest commit and the 177 errors that it detects? I think we can achieve that with `pre-commit`, although we need to explicitly pass all necessary.

This new hook replaces the one below, which is disabled by default

```
-   repo: https://github.com/pylint-dev/pylint
    rev: v3.0.1
    hooks:
    -   id: pylint
        stages: [manual]
        args: [--load-plugins=pylint.extensions.redefined_loop_name]
```

Given that I can't fix all the errors within 1 PR, let me know how should I proceed My main curiosity is how many of the 177 errors are ruff-pylint checks that are not enabled in the current pylint checks? https://github.com/pandas-dev/pandas/blob/cad0d87c63a914ebc6e33fb1b5e22c9068d75710/pyproject.toml#L369

Ideally this PR should just bump ruff and enable ruff-pylint, and all modifications are updates from other rules.

Then in a follow up PR, the old pylint can be removed (and optional ruff-pylint rules can be enabled too) hi @mroeschke, please take a look at the last commit, where I manage to make an automatic translation of `pylint` config to `ruff` config with the help of [`pylint-to-ruff`](https://github.com/akx/pylint-to-ruff).

Given the list of `pylint` rules that has not been implemented in `ruff` (the one that's commented out), let me know if it's ok to drop `pylint` in favor of `ruff` @mroeschke thanks for your review. I rebased on `main` hi @mroeschke, I wonder if we should split the version bump of `ruff` with the switch from `pylint` to `ruff` so that we can use the latest `ruff` version first. 

I can also take a look at the rather messy bump from `0.2.0` to `0.3.0` if it's good for you Yes I think that's a good idea to bump ruff to 0.3.0 first before doing a pylint migration Coming back around to this; to simplify the transition I think we can just enable the pylint rule in ruff (and ignore the non-fix rules that don't pass currently) and remove the pylint config in pre-commit-config. I think it's OK to not exactly have a 1:1 transition between the old and new pylint configuration Thanks @tqa236  thank you for finalizing this PR, I was on vacation and didn't have time to check your last message.