String dtype: turn on by default
Now that 2.3.0 is released, time to switch the default on main to prepare for a 3.0 release (and also such that people using nightlies get this)

I assume this might also still uncover some failing tests. And the docstrings will still fail for sure.
cc @rhshadrach I remember you gave the feedback when CoW option was removed (actually removed, without ability to turn CoW off), that it might be good to keep the option working for some time? (so that if you run into issues, you can still turn it off temporarily) 

Shall we do that here?

And if we do that:
- do we want to keep some CI testing that? (for example I could keep the build currently testing turning it on, but then with turning it off)
- add a warning for people setting the option to False that this is only kept working temporarily? Aside docstrings, the only tests that were failing are the ones with the minimum pyarrow dependency of 10.0.1. For our support window of 2 years, we can bump that to 12.0.1. If that helps, will move it to a separate PR. > Shall we do that here?

I would like to keep the option for users to switch back to the old string type if needed  Any idea how many xfailed tests are specific to this? I saw some this morning, will see if I can address those. looks like 20 tests (76 with parametrization) are xfailed.  At least some of these will be easy-but-tedious of updating `expected`s that I'll get out of the way now.  I don't see any reason why these would be a blocker for this PR. To be able to move forward with enabling this on main, I added commits to temporarily disable failing CI for doc build or doctest failures. That will require more fixes, but also can only be done when this is enabled, and I would prefer doing that in separate (potentially multiple) PRs instead of doing it all at once. 

Another alternative would be to just keep the option disabled specifically in those builds (by setting `PANDAS_FUTURE_INFER_STRINGS=0` in those builds), so they can keep running and testing for now. But for the docstests, that still gives the same problem that then fixing them needs to be done in one go, so I think for doctests I prefer disabling errors temporarily, and then fixing all failures in separate PRs. For the main doc build part, I have opened https://github.com/pandas-dev/pandas/pull/61864 to start fixing the build issues with the string dtype enabled I'm fine with the two-step approach here + #61864.  @rhshadrach @mroeschke happy here? +1