DOC: Fix code style in `any` and `all` methods
change double quotes to single quotes

- [ ] 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.

thanks for your PR, but please don't do this to any repo

closing then, please search 'good first issue' if you want something to contribute to, and check the contributing guide https://pandas.pydata.org/docs/dev/development/contributing.html I saw mixed usage of both in those code examples, so my logic was that must be a mistake.
But I might have mistaken which style (double or single) is recommended in Pandas.
Is that what you are referring to? or just "code style" commits in general?

I don't see why I shouldn't have done this, unless mixed usage of both is valid in terms of recommended style guide. this is the kind of thing we'd only do with an automated checker, please don't do it by hand could do with some help on  https://github.com/pandas-dev/pandas/issues/37875 if you're interested in docs / stylistic issues Does the automated checker also check code examples in docstrings?

Because I looked at some more methods and there were many more cases of this mixed usage of single & double quotes.

So I thought maybe it's the checker's fault for letting this happen in the first place.

**_The ones with mixed usage:_**
```
info
insert
lt
gt
le
ge
ne
eq
agg
aggregate
transform
groupby
all
any
...
```

**_The ones with double quotes:_**
```
set_flags
convert_dtypes
infer_objects
copy
get
expanding
...
``` I came across this today and see that the discrepancies still exist in the docs...

Is this not considered an issue? Maybe not a critical issue, but still, it's an eyesore...
 If there is a linter that can check and fix this automatically, I think we would be happy to take a PR for that one complication is pandas' complicated docstring substitution mechanism...I don't it would be too easy to fix this automatically, but it should be possible to verify that it's done by amending

https://github.com/pandas-dev/pandas/blob/aa3e949e2a2b72588186cb1936edb535713aefa0/scripts/validate_docstrings.py#L194-L211

to do some other check

not sure it would be worth it, and i can't commit to reviewing at this time, just pointing it out as a possibility