Refactor Expr

This is a large pull request.  Sorry.


### Remove TableExpr, generalize to Expr

We're breaking away from just tables.  To be clear compute functionality is still only support for Tables.  The expression system is now general enough to handle a richer variety though.

### Remove ScalarExpr, generalize to Expr

Same as above, the new Expr system is general enough to handle scalars too.  This simplifies a previous wart in our design.

### Method dispatch

We avoid creating instance methods and prefer creating bare functions.  We wire these bare functions on to expressions (so that they look and feel like methods) based on the datashape of the expressions.

This is bad because it's very custom/magical.  However I think that this will be useful in two fundamental ways

1.  This specializes the API according to the datashape, narrowing choices
2.  This removes substantial barriers to Array/Table/Expr interoperation.

### Hide internal attributes

We're trying to minimize the public facing API.  This includes hiding attributes like `.name`, `.args`, `.traverse` so that users only see what they need.  To be clear this prefers naive users over expert ones.

### Generalize type checks to predicate functions

Anywhere you used to see `isinstance(expr, TableExpr)` we now use predicates on datashapes like `iscollection` and `isnumeric`.  Depending on a type hierarchy within expr is likely to break quickly as we mix tabular, document, and array operations.

Note, we still depend on types for `compute` dispatch.  This still works like a champ.

### Renamings

Things like `Column/.columns` become `Field/.fields`, `TableSymbol` becomes `Symbol`, etc... I'm supporting backwards compatibility for a bit.  Users should expect some API breaks though.

### Strict behavior around record types

The schema `{name: string}` is now strictly not a single column, it is a record type (e.g. tuple with single element.)  To be a column-like thing (e.g. pandas.Series or list-of-ints) your datashape must satisfy `datashape.isunit(ds.measure)` like `string` or `int32`.

The name of a column is now part of the expression, not the datashape.  This is stored under the `_name` attribute.

This breaks user-facing APIs with `map(iscolumn=True)` and `TableSymbol(iscolumn=True)`

### Break out tabular expressions to a few different files

E.g. `collections.py`, `reductions.py`, `split_apply_combine.py`.  This is somewhat arbitrary.

### Built off of Phil's datetime branch

The first set of commits here are from Phil's work in #661 .
i know we're generally -1 on adding new backends ATM, so that we can focus on core infrastructure but would it be useful to start thinking about a dynd backend? i know we have `into` defined for many pairs of `dynd, other` but it could be useful to try to do `compute` operations on dynd. i bet this would expose missing functionality in dynd and maybe help clarify what's needed to make it work to back other parts of blaze