BUG: fix StringDType partition and replace with mixed string and object operations - #33215

PR summary

np.strings.partition, rpartition, and replace accept object operands for fixed-width unicode input but fail for StringDType input:

In [1]: import numpy as np

In [2]: u = np.array(['abc', 'xbx'])

In [3]: sep = np.array(['b', 'x'], dtype=object)

In [4]: np.strings.partition(u, sep)[0]
Out[4]: array(['a', ''], dtype='<U1')

In [5]: np.strings.partition(u.astype('T'), sep)[0]
...
TypeError: data type 'T1' not understood

In [6]: np.__version__
Out[6]: '2.5.4'

result_type(StringDType, object) is object, so these calls fall through to the fixed-width code path, which can't build a StringDType output. This PR converts object operands to the input's StringDType first, following the fixed-width path's rules, so StringDType behaves like unicode. For a StringDType with an na_object, a missing value passed as an operand becomes a null and gets the usual StringDType null error.

replace rejects object dtype before calling result_type but it's still possible to trigger this in replace using StringDType's missing data support, see the tests.

Converting values like None to strings is itself questionable: str methods and np.char in NumPy 1.26 raise TypeError. Aligning the two dtypes first means a possible follow-up deprecation can treat both the same way.

A Quansight client found the partition bug. I don't think this is worth backporting to 2.5.x, since it doesn't apply cleanly.

AI Disclosure

I iterated on this with an AI model.