REF: only fallback to masked op for object dtype

[jorisvandenbossche]

While investigating #40727, I noticed that we are often trying _masked_arith_op, while it will end up giving the exact same error (for example when using ints, which don't have NaNs).
From what I understand, I think that, in theory, we only need to fallback to a masked version of the op when having object dtype (I might be wrong here, though). So this PR tries that.

For numeric dtypes, all operations should simply work with NaNs?
For object dtype, we can have NaN or None, which doesn't necessarily work out of the box, so here we need to fallback to a masked operation.
ExtensionArrays don't end up here, and datetimelike dtypes get wrapped into EAs before getting here.

[jorisvandenbossche]

Catching the error here, instead of higher op in _na_arithmetic_op, ensures that we try again with the plain standard op instead of directly try again with _masked_arith_op

[jbrockmendel]

just ran all the tests asserting that we only get here with object dtype, and found that the failures were floordiv/rfloordiv (handled by #40727) and operator.pow (note: not the same object as pow) with integer dtype. does this handle the latter case?

[jorisvandenbossche]

See my inline comment at https://github.com/pandas-dev/pandas/pull/40728/files#r605632277, that's handling the integer pow case (by catching that error within expressions.py, so it falls back to _evaluate_standard (the plain op) within expressions.py, and not to _masked_arith_op in array_ops.py)

[jorisvandenbossche]

Now, there are still some failures in test_expressions.py that I need to look at (but since those are testing directly expressions.py, it might also be that I need to update tests)

[jbrockmendel]

sounds good. also looks like with this we can get rid of the last usage of maybe_upcast_putmask

[jorisvandenbossche]

It was actually a bug in my change in the reversing of the operands

[jreback]

thanks @jorisvandenbossche