[WIP] Refactor Expr

This is a large pull request.  It does a few things (sorry).


### Method dispatch

We avoid creating instance methods and prefer creating bare functions.  We wire these bare functions on to expressions (so that they look like methods) based on properties 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, opening doors for future expansion of the expr interface

### Rename the `name` attribute on columns to `_name`

This was annoying in that functions had to check "wait, did he mean the name of the column, or a column named 'name'?"

### Move element-wise-like operations from `TableExpr` to `Expr`

In particular text operations like `Like` and datetime operations like `Week`, `Day`, `Month` are generally applicable to `Expr`s as well as `TableExpr`s.

### Generalize TableExpr checks

Now that we create things that the Python type system can't robustly identify as Tabular we switch to using predicate functions like `istabular` and `isscalar` rather than `isinstance(expr, TableExpr)`. 

### Starting to expand `Expr` as a first-class citizen

I'm starting to rename things like `Column` to `Field` and testing against more nested structures.  This work should eventually open Blaze to data structures beyond tables.

### Strict behavior around record types

The dshape `{name: string}` is now strictly not a single column.  To be a column-like thing (e.g. pandas.Series or list-of-ints) your datashape must satisfy `datashape.isunit(ds.measure)`

This breaks external APIs with map and `TableSymbol(iscolumn=True)`

### Create new generic Expr class `Collection` 

Means any Expr such that `datashape.isdimension(expr.dshape[0])`
@mwiebe does this behavior match your expectations?