REF: implement arithmetic, comparison, logical ops on arrays
Following #28413, #28396, and #28395, these are all pretty straightforward refactors.

`arithmetic_op`, `comparison_op`, and `logical_op` are going to become the ops that we call `Block`-wise.  Hopefully also `PandasArray` will use them directly.

Other follow-ups I have in mind:
- Move `should_extension_dispatch` and `dispatch_to_extension_op` so we dont need runtime imports
- get rid of `eval_kwargs` entirely, they're not really necessary at this point
- see if we can use `numexpr` for comparison/logical ops
- docstrings
- address inconsistencies in when we call `extract_array`
- address inconsistencies in how `Series` methods handle `__finalize__` and alignment
- simplify `logical_op`'s `na_op`
Added requested comments and types.  Holding off on docstrings since doing those right will be non-trivial. reverted types because mypy was complaining about indexes.base @jreback gentle ping.  This is the last blocker before I can implement block-wise ops for the scalar case (and one of the two Series cases) updated with types and bare-bones docstrings > this is mostly just a cut/paste yes?

Correct.  types and basic docstrings have been added. > can you move both extract_array's in here? would make groking this simpler

I agree that having extract_array in exactly one place is weird.  We'll be able to get rid of it after the integer-addition deprecation is enforced (and keep_null_freq becomes unnecessary).

The tradeoff is that doing all 6 extract_array calls inside the functions would break the typing "guarantees", which I'm starting to like. > > [@jreback] can you move both extract_array's in here? would make groking this simpler
>
> I agree that having extract_array in exactly one place is weird. We'll be able to get rid of it after the integer-addition deprecation is enforced (and keep_null_freq becomes unnecessary).
>
> The tradeoff is that doing all 6 extract_array calls inside the functions would break the typing "guarantees", which I'm starting to like.

I agree with @jbrockmendel that it is nice to already know what types are passed to those functions. So I think what is done in the PR (do extract_array outside, except for the one case where it is needed for the deprecated functionality) is fine. It's only temporary (we should remove that deprecation for 1.0), and gives the least code flux afterwards (only that one case can be moved out afterwards. rebased+green thanks @jbrockmendel couple of followup requests noted above