Small code change that has fairly large implications for how to think about the specification of a plot layer.

Previously, a layer was defined as a tuple of (Mark, Stat, Move), where Stat and/or Move were optional. This was extended to allow multiple Move operations, by also allowing (Mark, Stat, List[Move]). I would also like to support multiple Stat operations (e.g., Bin then Agg).

But the distinction between Stat/Move is not especially meaningful. I think it can be roughly defined in terms of Move only changing the values in the data, not the shape of the data, whereas Stat is allowed to change the shape. But both are fundamentally transforms that are applied to the data, in serial, before plotting.

So in the revised API, the distinction is collapsed, and a layer can be thought of simply in terms of "a Mark and some number of transforms." Rather than allowing "a Stat, or a Move, or a list of Stat(s) and/or Move(s)", transforms are accepted in a variable positional argument list. So the following calls are all now valid:

Plot().add(mark, stat)
Plot().add(mark, move)
Plot().add(mark, stat, move)
Plot().add(mark, stat, move, move)
Plot().add(mark, move, move)

For the time being, it would require substantial refactoring to actually treat Stat and Move operations the same and apply them at the same point in the internal data pipeline. So the API currently enforces some limitations: there can be at most one Stat, and it has to come first.

This is mostly backwards compatible with existing code based on the betas, with a few exceptions. The following no longer work:

Plot().add(mark, stat=stat)
Plot().add(mark, move=move)
Plot().add(mark, stat, [move, move])

I think that the new approach is superior: it's easier to swap a stat in/out if the move does not need an explicit keyword argument if it's missing, and juggling the multiple nested brackets required to pass a list of move objects is annoying. But there may be a little code churn if you've been playing with the beta, sorry. (The error message for cases where stat= or move= keywords were used is also a little confusing, you'll just get "ValueError: If using all scalar values, you must pass an index").

Needs before merging:

• Update to objects interface demo
• Potentially adding scales to all Move objects so that their call method has the same signature as Stat objects. We'd eventually need to do this, and might as well not worry about backwards compatibility.