ENH: change get_dummies default dtype to bool
Added a future warning when no dtype is passed to `get_dummies` stating the the default dtype will change to `bool` from `np.uint8`
- [x] Closes #45848 
- [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 an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.
Awesome, thanks for sticking with this @kianelbo  FWIW, this does cause some confusion for downstream consumers--for example the common approach of using `pd.get_dummies(pd.cut(...))` to get one-hot encoded data (common for ML applications) might more naturally be expected to continue to return a numeric type, which I believe is also the default for `sklearn.preprocessing.OneHotEncoder`. I actually plucked that approach right out of Wes' book I think.

Well, I'm not really that annoyed minus 90 minutes of debugging, and the fix is trivial for the consuming code (just specify the old default `dtype` to `get_dummies`), but I'll just place this comment here in case it helps others adapt their downstream code. It also lead to some not obvious errors in statsmodels when testing against the pre-prelease.  It wasn't that hard to change since I know about this change, but would have been hard to determine had one not. When making the changes I half wondered if the default should have become `double` which would have always prevented the math issues that this was desired to fix, albeit at the cost of 8x storage (although one could always choose `bool` if storage was more important than simplicity of use).