RFC: Clean up operators

There are two main goals here: to improve performance by allowing type inference to happen for most of these operations, and to reduce the amount of repetitive code. See #327 for more background.

Some notes:
- I'm not a huge fan of the giant lists of operators at the top of the file, but I left them in since they're used in `dataframe_blocks.jl`. My main grievance is that they make it hard to tell what's being defined where without jumping around in the file. A secondary issue is that the operator categories that make sense in `operators.jl` don't necessarily make sense elsewhere. For example, `./` needs to be defined separately in `operators.jl` for type reasons, so it's not in `array_arithmetic_operators`, and at the moment this also means it's not handled in `dataframe_blocks.jl`.
- Would it be reasonable to give all AbstractDataArrays `isna` and `data` methods that take indices? The `isna` method would return a `Bool`, and the `data` method would return `dv[i]` if `dv[i] != NA` and could return anything otherwise. Then I could remove the special cases for DataArrays and speed up other AbstractDataArrays.
- The pairwise and cumulative vector operators will give errors instead of returning NA when there are undefined values in the array underlying the DataArray, which can only happen for non-bits types. This is left over from the old implementation, and I'm not sure whether it's worth fixing, or how much effort it's worth putting into performance if I do.
- I only made cosmetic changes to `col*` and `row*`, but these could use some more work. The API should probably change to be more Julian (#159) and there are other considerations as well (see #325 and #259).
- I'm not too sure about the behavior of `all`. Whether we return `NA` or `false` depends on the order of the vector, i.e., `all([false, NA]) == false` whereas `all([NA, false]) == NA`. I haven't changed this, since I wanted the existing tests to pass, but is this really what we want?
- I didn't touch the `rle` methods, since I'm not sure they're sufficiently commonly used to be worth optimizing.
- I still need to go through the tests and make sure that the coverage is still somewhere close to full.