REF/PERF: ArrowExtensionArray.__setitem__
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/v2.0.0.rst` file if fixing a bug or adding a new feature.

Simplifies and improves performance of `ArrowExtensionArray.__setitem__` via more use of pyarrow compute functions and less back and forth through numpy.

ASVs:
```
        before           after         ratio
    [059b2c18]       [91049c37]
    <main>           <arrow-setitem>
-         382±2μs          336±1μs     0.88  array.ArrowStringArray.time_setitem_list(False)
-         900±5μs         566±10μs     0.63  array.ArrowStringArray.time_setitem_list(True)
-      14.0±0.3ms      6.12±0.06ms     0.44  array.ArrowStringArray.time_setitem(False)
-         345±6μs        99.6±20μs     0.29  array.ArrowStringArray.time_setitem_slice(False)
-      24.5±0.2ms      6.12±0.05ms     0.25  array.ArrowStringArray.time_setitem(True)
-     5.35±0.06ms          304±3μs     0.06  array.ArrowStringArray.time_setitem_slice(True)
```

Not for this PR but because I'm cranky: the fact that we have to implement a kludgy `__setitem__` sucks.  ideally pyarrow would implement it; failing that better to set into each of the elements of `self._data.buffers()` (which besides being a PITA im not sure is even possible in mask-less cases) > Not for this PR but because I'm cranky: the fact that we have to implement a kludgy `__setitem__` sucks. ideally pyarrow would implement it; failing that better to set into each of the elements of `self._data.buffers()` (which besides being a PITA im not sure is even possible in mask-less cases)

This was a (failed?) attempt to make it a little less kludgy :). Agreed its still kludgy. 

Part of the complexity is supporting older versions of pyarrow where the pyarrow.compute functions have bugs we need to work around. We could remove the fast paths if simplicity is preferred.

I'm not familiar with the buffers but could take a look.  > I'm not familiar with the buffers but could take a look.

Definitely don't put time into this on my account.  I've got a bug in my bonnet about preserving views (xref #45419) that becomes less important with CoW.  Plus as mentioned, im not confident that the buffers() approach is even feasible. Thanks @lukemanley 