re-imagined objectConcat (Fixes #458)

Now matching several additional patterns in objectConcat,
8 in all, meant to cover all the possibilites of known
shapes with a correct implementation for each combination.
Cases produced by wildcards are explicitly matched and
the existing merge-based code is used only in those cases.
If any other shape is encountered, the planner fails with
'unrecognized shapes' and we'll have to figure it out.

GroupBuilders now keep track of the source and keys they
are built from, even as expressions get folded into them.
This allows objectConcat to easily, definitively tell when two
GroupBuilders can be combined, without having to inspect keys,
which may have been rewritten. `GroupId` contains the list of
builders for the source and keys, but only the hashCode is
shown to keep the log clean.

Scalacheck tests for the planner, generating queries with
a combination of ExprOps, JS exprs, and reducing functions
in the projections, with and without a "group by" clause.
Assertions check for too many group and/or unwind ops, and
consecutive simpleMaps. This has been *very* productive in
finding problem cases, and can easily be extended to other
type of queries.

One pending scalacheck test for a problematic case (see #469).

Many tests now have nicer tmp names (fewer missing numbers),
and one or two got worse.

Random JS-generation stuff:
- `JsMacro.compose`
- Fixed indent for JS object constructors.
- Switched some `toJs` methods to JsMacro (the last, I think).
- Some `Access` nodes became prettier `Select`s.

Fixed the untyper for math functions.
update for IsNull from master
test for `compose`

Is this the right semantics? Can’t decide for sure, but I think this is
actually `>>>`/`andThen`.
respond to feedback
- renamed `compose` to `>>>` because that's what it's doing and it seemed clearer
to keep it that way given how it's being used.
- reference #471 in a TODO
- fix/simplify untypers for the math funcs
Merge pull request #470 from mossprescott/ready/458

re-imagined objectConcat (Fixes #458)
generalize Search implementation (Fixes #416)

Implement Search for arbitrary string arguments (not just constant string
patterns). Also implemented Search in JS for use outside filtering.

All query expressions typed as constants are now inlined in the logical plan.

Add additional cases to `WorkflowBuilder.merge` to avoid calling
`toCollectionBuilder`, resulting in dramatically flattened $simpleMaps
and $projects in many cases. We should not be creating any nested temp
objects at this point, unless I missed something. Note: this makes it
much easier to spot redundant projections (projecting the same value
under more than one temp name). We'll want to get rid of these (see #474).
add missing data set reference
respond to PR feedback
- couple of TODOs referenceing new issues
- combine Validations with |@|
Merge pull request #475 from mossprescott/ready/416

generalize Search implementation (Fixes #416)