Implement String Accumulations with nanoarrow

[WillAyd]

This is an addon to the great work that @rhshadrach is doing in #60633

Here is performance on this branch:

In [1]: import pandas as pd

In [2]: import pyarrow as pa

In [3]: ser = pd.Series(["foo", "bar", "baz"] * 10000, dtype=pd.ArrowDtype(pa.string()))

In [4]: %timeit ser.cumsum()
504 ms ± 29.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [5]: %timeit ser.cummin()
1.23 ms ± 12.6 μs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

In [6]: %timeit ser.cummax()
1.23 ms ± 36.5 μs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

versus without nanoarrow:

In [1]: import pandas as pd

In [2]: import pyarrow as pa

In [3]: ser = pd.Series(["foo", "bar", "baz"] * 10000, dtype=pd.ArrowDtype(pa.string()))

In [4]: %timeit ser.cumsum()
1.72 s ± 47.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [5]: %timeit ser.cummin()
1.49 ms ± 81.2 μs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

In [6]: %timeit ser.cummax()
1.58 ms ± 42.9 μs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

While they all show some improvement, cummin / cummax don't show as much. I believe this has to do with the fact that the implementations still have to access the Python runtime within a tight loop to perform comparisons. If we cared to optimize further, we could look at utf8proc

[WillAyd]

Ideally we would use the meson WrapDB entry, but in this case there's an upstream bug in nanoarrow that prevents us from using the latest release (0.6.0). See also apache/arrow-nanoarrow#702

Whenever 0.7.0 gets released we can go back to using the Meson WrapDB entry, although I don't think there is any huge rush for that either