Support setproperty as well to modify columns in place

[piever]

In the same way as Tables implements getproperty for a "lazy row" of a NamedTuple of vectors here, I wonder whether it should also implement setproperty!. This is a nice bonus of using a lazy row rather than a NamedTuple for iteration: we can get DataFramesMeta's @byrow! for free. For example:

foreach(rows(df)) do row
  row[:c] = row[:a] + row[:b]
end

[quinnj]

Certainly something worth considering; it would definitely have to be optional, since a number of sources couldn't support this (CSV row-iterator, SQLite table row-iterator, etc.), but for those that could, it would certainly be handy.

[quinnj]

I don't think there's anything Tables.jl-specific here; if a custom Row type wants to support setproperty!, then there's nothing stopping them from doing so and documenting that it works. It isn't something the Tables.jl interface needs (or wants) to enforce though (NamedTuples already couldnt' support this).

[piever]

Maybe one thing that could be done on the Tables side is to add a setproperty! method to the default fallback for row iteration of a columnstable (where each row is a ColumnsRow). Say:

function Base.setproperty!(c::ColumnsRow, nm::Symbol, x)
    getproperty(getfield(c, 1), nm)[getfield(c, 2)] = x
end

In this way it would be clear that all column based storage can have a setproperty! method on rows (and they would, by default, if they don't implement a "non-fallback" row access).

[quinnj]

With #131 merged, I'd like to commit to a simple, generic Tables.jl interface that is mainly about table transfer and consumption. I've proposed in another issue that it seems to make sense to get together and define a stricter interface that would support in-place and mutating operations.