REGR: ensure DataFrame.select_dtypes() returns a copy
- [x] closes #48090
- [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.


This was caused by the performance improvement in #42611, because `_mgr._get_data_subset` doesn't return a copy in contrast to indexing columns with `iloc`. This just adds a copy option to `_get_data_subset`, to keep all other improvements from #42611 (the performance obviously decreases again because of the additional copy, but it's still faster than before #42611)
the original patch was for performance 

this preserves? @jreback see the explanation in the top post

This preserves _part_ of the performance improvement. But the improvement of https://github.com/pandas-dev/pandas/pull/42611 "too big" since it also removed a copy of the data that it shouldn't have.  can u show the asv results Using the same code snippet as in https://github.com/pandas-dev/pandas/pull/42611, I got:

```
In [2]: %timeit self.time_select_dtype_string_exclude(dtype)
1.64 ms ± 158 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)  <-- previous code before perf improvement
38.5 µs ± 279 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)  <-- main
740 µs ± 17.9 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)  <-- this PR
```

The slowdown compared to main is fully due to the copy. All the other improvements from https://github.com/pandas-dev/pandas/pull/42611 still give a 2x improvement compared to before. great ty

this actually somewhat answers the question of how CoW would impact (asked in another issue) if we do end up adding `copy=True` keywords where relevant, could do the same here eventually all green, I think all comments addressed. will merge later today if no objections. > will merge later today

b4 1.5.0rc0 Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
git checkout 1.4.x
git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
git cherry-pick -x -m1 f6e9b1a4643affbc0d5ce9f363bb37c5ace35bc4
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
git commit -am 'Backport PR #48176: REGR: ensure DataFrame.select_dtypes() returns a copy'
```

4. Push to a named branch:

```
git push YOURFORK 1.4.x:auto-backport-of-pr-48176-on-1.4.x
```

5. Create a PR against branch 1.4.x, I would have named this PR:

> "Backport PR #48176 on branch 1.4.x (REGR: ensure DataFrame.select_dtypes() returns a copy)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                