Canonicalize blaze server dshape formatting.

[kwmsmith]

Non-Python clients (like JS) can get tripped up with different
formatting in dshapes.

For instance, small record dshapes, like:

var * {a: int32, b: float64}

are stringified by default on one line, but longer dshapes, like:

var * {
    sepal_length: float64,
    sepal_width: float64,
    petal_length: float64,
    petal_width: float64,
    species: ?string
    }

are stringified onto several lines.

This commit ensures that all datashapes are stringified in a consistent
way, regardless of the number of components in the dshape or the
dshape's overall string length. Again, this is motivated by non-Python
clients that expect a consistent formatting for dshapes.

This has little effect for Python clients, as they can simply re-hydrate
the dshape on the client side and interact with the DataShape object
API.

The server tests were modified to not compare the string form of dshapes
directly; instead, they use datashape.util.testing.assert_dshape_equal().

The long-term solution to this is to separate the serialization of
dshapes from their string representation. This would involve defining
something like to_tree() and from_tree() for DataShape objects, and
allow clients to represent the serialized dshape contents however it
chooses.

[llllllllll]

I feel like the string representation of the dshape is the best serialization format. Maybe what we need is a javascript implementation of the datashape parser. I am okay with this change for now though.

[kwmsmith]

I am okay with this change for now though.

OK, merging.

I feel like the string representation of the dshape is the best serialization format. Maybe what we need is a javascript implementation of the datashape parser.

See blaze/datashape#204.