BUG: raise when doing arithmetic on DataFrame and list of iterables
- [X] closes #36702
- [X] tests 1 added / 1 passed
- [X] passes `black pandas`
- [X] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [X] whatsnew entry

## Problem

We currently allow doing arithmetic on a DataFrame, and, for example, a list of Series. The latter gets broadcast with `align_method_FRAME` and this leads to weirdness.

## Solution

We should raise. There is no definite answer to how such arithmetic should be handled, and the user should just make another DataFrame and add that to the frame instead of doing stuff like `[Series, Series]`. 

cc @jbrockmendel  Ran indexing benchmarks three times, no stable regressions on my machine.
I'm running the benchmark suite on Ubuntu inside Windows with plenty of free CPU and memory, but I still saw different 2-5 regressions / improvements during the three runs that I did. Sorry, don't have a dedicated machine for benchmarking, and my setup isn't always stable (probably because of all the junk in Windows grabbing and releasing resources).
We should be fine, since no regression or improvement held across runs. @jreback 

Made the change suggested by @jbrockmendel , all green. thanks @AlexKirko nice! Unfortunately this fix breaks `test_arith_frame_with_scalar` for my custom `ExtensionArray`. I have to say that my type is a bit "weird" in the sense that indexing it gives a object of the same type (like the string type in the standard library). This fix does not seem to like that very much. @vnmabus can you give a link or example? I have two extension arrays in https://github.com/GAA-UAM/scikit-fda, `FDataBasis` and `FDataGrid`. Both of them are used to represent a sample of functions (functional data). However, for simplicity, as I did not want to create a "just one function" object to represent a scalar value which won't be used much, I made `__getitem__` with an integer key return an object of the same kind and length 1.

These extension arrays (mostly) work with Pandas, but this fix raises an exception, as they are "list like" and the elements (that is, the same class) are "array like". Yo can see the error here: https://github.com/GAA-UAM/scikit-fda/runs/3037343824. Haven't looked at this too closely, but I think _maybe_ if you make `FDataAFoo.__iter__` yield the scalars (functions) that might avoid this particular problem.  That would mean an inconsistency between `list(fdata)` vs `[fdata[i] for i in range(len(fdata))]` though. The thing is that currently there isn't a separate class for the scalars. A scalar in my case is just an object of the same kind but with length one. Yah I don't see any obvious way to avoid inconsistencies.  If this is a serious problem, I'd suggest opening a new issue for dedicated discussion