Split WorkflowBuilder into a number of case classes:

* CollectionBuilder – basically the same as the old WorkflowBuilder;
* ValueBuilder – holds a literal;
* ExprBuilder – holds some expression;
* DocBuilder – holds a flat projection; and
* GroupBuilder – holds some grouped structure – can be an expression, an
  accumulator (`GroupOp`), or a projection.

Also:

* ensure that we run `sbt` from the top of the repo in the `ready` script;
* fixes issue #403 (order of projections matters);
* fixes issue #405 (group by constant);
* fix a matcher that reversed the expected/actual sides in the diff;
* take `GroupOp` out of the `ExprOp` hierarchy;
* get rid of a broken Workflow.merge case;
* fix typers for distinct[By];
* fix “plan simple constant example 1” (prev. pending test);
* fix “plan complex group by with sorting and limiting” (prev. pending test);
* remove dead code (`FieldProject`) from SchemaChange;
* add lots of cases where WorkflowBuilder errors if we can identify a
  bad query statically;
* fail `ArrayLength` if called with a non-1 dimension;
* clean up some FIXMEs and TODOs (Or at least associate with issues when
  possible); and
* add a rewriteRefs helper function.

That probably misses a bunch, but it’s what I managed to catch in commit
messages along the way.
`lift((x |@| y)((_, _))).flatMap(_ match { ...`! Really? Is this kind of thing to be tolerated?

Surely there's a less convoluted way. `lift((x |@| y)((_, _) match { ...` or something to that effect would be a slight improvement.

Better yet, an operator that does the tupling, so you could just write `lift((x |@| y) { case (a, b) => ...`. But I gather |@| is already a bit of a hack, so I don't know if that's feasible.