BUG/API: disallow boolean arithmetic operations
closes #6762

cool...merge on green
 crap just realized this will fail on py3 ... `operator.div` isn't there anymore only `truediv`
 less trivial than i thought ... will finish in a bit
 @cpcloud @jreback I know this is already merged some time, but just stumbled on this. Is there a good reason to disallow this? Because it is an API change (so people could rely on this behaviour), _and_ it does also work in numpy this way (at least for + and *).
 no this only disallowing silly things

True + True
True \* True works but you should just use &
 Is this silly?

```
In [18]: pd.__version__
Out[18]: '0.13.0'
In [19]: s = pd.Series(range(5))
In [20]: (s > 1) * (s < 3)
Out[20]:
0    False
1    False
2     True
3    False
4    False
dtype: bool
```

I know we say: just use & instead. And no problem at all that is the recommended way. 
But above code now fails, while it was working previously. So potentially people could rely on this. Certainly given it also works this way in numpy:

```
In [21]: (s.values > 1) * (s.values < 3)
Out[21]: array([False, False,  True, False, False], dtype=bool)
```

So I was just wondering if there is a good reason to disallow this, apart from "people should use &"
 it breaks Numexpr and so will simply raise
if u r doing boolean ops you should use boolean operators

it will fail loudly

it didn't work before if the frame was big enough (and hit Numexpr)
 this was disallowed because numexpr doesn't have the op codes to deal with ops like 

``` haskell
Bool OP Bool -> Bool
```

where `OP` is a (non-bitwise) arithmetic operator (e.g., `+`, `-`, `*`, `/`). It should either fail across the board or work across the board (the board being either numexpr is used or it's not) but since numexpr doesn't work with those ops (IMHO rightly so) we have to make it fail. It shouldn't work for objects < some size threshold and then not work for larger objects
