REF: consistent ndarray-wrapping for lists in arithmetic ops

[jbrockmendel]

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

Discussed in #62423 among others. This ensures we wrap list in np.array at the top of all arithmetic/comparison/logical methods*.

* Not quite accurate. For logical methods on numpy dtypes we deprecated and now disallow dtype-less sequences. So this does the wrapping on EAs, but doesn't revert that deprecation for non-EA cases.

As a result, Series[dt64] - [datetime_obj] no longer raises. Note that it does return object dtype, which is not what the user in #62524 wants.

This also results in a changed dtype for test_add_list_to_masked_array.

Update I'm working on a branch to deprecate wrapping for tuple and non-list is_list_like(other) and not hasattr(other, "dtype")

[jbrockmendel]

The alternative to np.array is sanitize_array (effectively pd.Series(the_list)._values). That would break the Int64 case bc the None would be cast to NaN.

[jbrockmendel]

Discussed on the dev call this week to (I think) general approval that np.array-wrapping is the simplest, most consistent behavior available and that users who want something else can pretty easily do that themselves.

That said, I've found three issues where this would enshrine behavior that users complain about: #54554, #62524, #62353. In each of those cases the list contains datetimes or timedeltas. Calling np.array on it returns object dtype, where the users expected dt64 or td64.

I still think np.array is the right move here, but want reviewers to be aware of the tradeoffs.