CLN: Remove mangle_dupe_cols argument
- [X] xref #47718
- [X] [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
- [X] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [X] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [X] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Addressing #47718 step by step. Here I remove the `mangle_dupe_cols`, which was never implemented. I directly remove it, instead of showing deprecation, because I don't think in practice this should be breaking code. For example, the next code:

```python
pandas.read_csv(fname, mangle_dupe_cols=False)
```
Would raise an exception in all cases. So, I don't think making it showing a warning before raising the exception should be very useful. There could be the case of someone using:

```python
pandas.read_csv(fname, mangle_dupe_cols=True)
```
Where the `mangle_dupe_cols=True` literally does nothing as it's the default. If people were doing this it'd make sense to show a `FutureWarning`, but I don't see any reason why anyone would do that. So, in practice, I think we'd just be overcomplicating things with the deprecation in this case, and I think it's better to simply delete it.

We have deprecation in 1.5 for an unused argument in a function, so there's precedence for also adding a deprecation here too https://github.com/pandas-dev/pandas/pull/47728. It would make this PR a little more complicated as you said (change default arg to `lib.no_default` and raise warning if True was passed)

Would this close https://github.com/pandas-dev/pandas/issues/13262 and https://github.com/pandas-dev/pandas/issues/8908 as well? Thanks for the feedback Matthew. Feels it may be a bit too much conservative in my opinion, but if this is what was agreed and what we've been doing, I'll better add the deprecation then. This should close the issues you mention too, thanks for the reminder.

I'll implement the deprecation in a separate branch, as there is not much that can be reused here. So, closing this PR.