Speedups, bugfixes, and fleshing out current AbstractDataFrame API

@tshort The third commit is the one of interest, where I shuffled around code between DataFrame and AbstractDataFrame, and fleshed out a transient interface
I agree that there are tradeoffs here. I'd probably just leave it as you've got it and hold off on introducing another abstract type for a while. While I don't understand Jeff's coming changes in the type system, it seems that they may remove or change what `<:` means. 

Also, there could be various AbstractDataFrames. Some might want to support everything a DataFrame does and add features from there. Something like an IndexedDataFrame comes to mind where an index is kept for columns. Some might be read-only like a view into an HDF5 file; that would obviously be missing many features. If those are defined for AbstractDataFrames, they will error. Varying feature sets make it a little tricky to define what it means to be a DataFrame, and this impacts what additional abstract types we might want to have.