BUG: DataFrame reductions losing EA dtypes
- [x] closes #51446 (Replace xxxx with the GitHub issue number)
- [x] closes #42895
- [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).
- [ ] 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.

In the absence of 2D EAs, we need reductions to sometimes pretend the EA is 2D.  Enter "keepdims" adapted from numpy reductions.

This is still pretty ugly. I'm open to ideas to clean it up.

cc @rhshadrach any other particular cases need testing?
gentle ping @rhshadrach not looking to merge anytime soon but for thoughts on the approach I've looked into this PR after you pointed it out. I had missed this PR unfortunately...
 
I like the keepdims on the arrays approach, it's a natural way to way to keep the dtype information that is being lost in reductions to scalars, rather than doing it on the frame as in my approach. I'm not a super fan of picking `"keepdims"` from the kwargs everywhere though, it seems brittle that it's necessary to add that to so many places.

I think adding a `keepdims=False` parameter to the signature of `ExtensionArray._reduce` and wrapping the returned scalar value there when `keepdims` is True before passing it on could be simpler? Then you wouldn't have to consider keepdims in all the reduction methods. That approach will also take care of wrapping the `NA` values that doesn't get wrapped currently.

Also, because I did #52707 from the point of solving #40669, I had a focus on frames with `min_count=1`. Many of the tests in #52707 fail in this PR currently (because NA result aren't wrapped in this current implementation), so those should be considered here also IMO.

I can take a closer look if the above approach works, if that's ok with you? > I can take a closer look if the above approach works, if that's ok with you?

sounds good Closing in favor of #52788