WIP use Tables.Columns instead of `columntable`

[kleinschmidt]

This uses Tables.Columns as a (potentially) lightweight wrapper around input tables that does not convert them to the strongly typed NamedTuple of Vectors representation. This might make some things easier on the compiler (e.g. #220 ).

Requires Tables 1.6.0 since that's when Columns stopped being a lie ;)

There's some design issues to work out here still, since a generic NamedTuple could be EITHER a column table (if it contains vectors) or a single row, and there are a handful of methods that specialize on that to provide special handling (most notably modelcols(::InteractionTerm, ...)). What we PROBABLY will need to do is to add parallel methods for Row in a similar fashion, but I'm not sure about that. In the mean time, merging this would be breaking since you lose first class support for named tuples of singletons, which is part of the current public API. There may be a way around that but I haven't dug into it yet...

[nalimilan]

There's some design issues to work out here still, since a generic NamedTuple could be EITHER a column table (if it contains vectors) or a single row, and there are a handful of methods that specialize on that to provide special handling (most notably modelcols(::InteractionTerm, ...)). What we PROBABLY will need to do is to add parallel methods for Row in a similar fashion, but I'm not sure about that. In the mean time, merging this would be breaking since you lose first class support for named tuples of singletons, which is part of the current public API. There may be a way around that but I haven't dug into it yet...

For which situations do we need modelcols to take a row? For clarity, we could require row objects to be Tables.AbstractRow even if Tables.jl doesn't require that. Otherwise confusing things could happen (weird errors when the Tables.istable check fails for some reason...).