Arrow string array dtype
This is a continuation of https://github.com/pandas-dev/pandas/pull/35259, updated to use a single `StringDtype` parameterized by `storage` (python or pyarrow). We do use different classes for the array though.

I wouldn't recommend reviewing this yet. In particular, I need to refactor the string ops implementation. That will likely be done in a separate PR to keep things smaller here.

```python
In [1]: import pandas as pd

In [2]: a = pd.Series(pd.array([pd.NA, pd.NA], dtype=pd.StringDtype("python")))

In [3]: b = pd.Series(pd.array([pd.NA, pd.NA], dtype=pd.StringDtype("pyarrow")))

In [4]: a.array
Out[4]:
<StringArray>
[<NA>, <NA>]
Length: 2, dtype: StringDtype[python]

In [5]: b.array
Out[5]:
<ArrowStringArray>
[<NA>, <NA>]
Length: 2, dtype: StringDtype[pyarrow]
```

Closes https://github.com/pandas-dev/pandas/issues/35169
Just FYI @xhochy. @TomAugspurger I would continue to work on this starting next week again. Do we want to coordinate somehow? Closing in favor of https://github.com/pandas-dev/pandas/pull/35259 (hopefully) @TomAugspurger @xhochy OK to merge these changes into #35259? I'm not sure if we have complete agreement over how this will be exposed to the user yet in https://github.com/pandas-dev/pandas/issues/35169. This PR was taking a strong opinion on

1. One user-facing `pd.StringDtype[storage]`, parametrized by storage = `python/pyarrow`.
2. One or two (or three) user-facing  StringArray classes, an `ArrowStringArray`, `PythonStringArray`, and maybe a base `StringArray`.

Given the uncertainty around the API here, I'd prefer to just move forward with an internals-only `ArrowStringArray` and decide on the exact API later (unless we can agree on something quickly). > I'd prefer to just move forward with an internals-only `ArrowStringArray`

OK, i've just changed #35259 so that the doctest passed. I should probably revert that change and change the doctest so that ArrowStringDtype is not a top level import.




 Personally, I think there is enough agreement to at least start making a concrete PR, which will more easily trigger further discussion on it. 
(but let's bring this up again in the issue). That said, I think it's certainly fine to focus on the actual implementation in #35259, and leave the user exposing API for a separate PR. There is already more than enough to review and discuss for the internal implementation details ;) I don't seem to able to push to this branch. will open a new PR > I don't seem to able to push to this branch. will open a new PR

#39908