CLN: Don't use astype_nansafe after to_numpy
I'm not 100% sure about the change in the tests, but it seems to align with numpy:
```python
[ins] In [1]: np.array([1, 2]).astype(str)                                                                                                                                                                   
Out[1]: array(['1', '2'], dtype='<U21')

[ins] In [2]: pd.array([1, 2]).astype(str)                                                                                                                                                                   
Out[2]: array(['1', '2'], dtype='<U21')
```
```python
[ins] In [1]: np.array([True, False]).astype(str)                                                                                                                                                            
Out[1]: array(['True', 'False'], dtype='<U5')

[ins] In [2]: pd.array([True, False]).astype(str)                                                                                                                                                            
Out[2]: array(['True', 'False'], dtype='<U5')
```
Personally, I think those rather should convert to StringArray > Personally, I think those rather should convert to StringArray

Interesting idea, that does seem better > Personally, I think those rather should convert to StringArray

not at all, `str` conversion here is NOT the same as `string`. @dsaxton can you merge master > not at all, str conversion here is NOT the same as string.

That's true. So in pandas, we generally see `astype(str)` or `dtype=str` as converting to strings *as object dtype. But that's not what this PR is doing. So the question is whether we want to be consistent with numpy (convert to numpy string dtype), or consistent with pandas (convert to string as object dtype).

But so, I personally think we can already interpret `str` to mean StringDtype if the array you start with is already using a nullable dtype (it's one thing less to deprecate in the future, and it's not a backwards incompatible change since StringDtype is opt-in anways). > > not at all, str conversion here is NOT the same as string.
> 
> That's true. So in pandas, we generally see `astype(str)` or `dtype=str` as converting to strings *as object dtype. But that's not what this PR is doing. So the question is whether we want to be consistent with numpy (convert to numpy string dtype), or consistent with pandas (convert to string as object dtype).
> 
> But so, I personally think we can already interpret `str` to mean StringDtype if the array you start with is already using a nullable dtype (it's one thing less to deprecate in the future, and it's not a backwards incompatible change since StringDtype is opt-in anways).

I disagree, we *always* have `str` to mean string / object, NEVER `string`. I think changing this is way out of scope; changing for nullable types is VERY confusing. so -1 on this. > we always have str to mean string / object,

Which is also *not* what this PR is doing ...