Validate and into

First, this extends the `validate` operation in https://github.com/ContinuumIO/datashape/pull/44 to `Array`s, and `nd.array`s.  These checks are much faster because they depend on the dshape information held by these objects.

Second, we add an `into` operation.  I stole the syntax from Clojure's [into](http://clojuredocs.org/clojure_core/clojure.core/into) which has slight different semantics.

What does this do?  It coerces our working types from one storage mechanism to another.  I.e. transformations like the following

```Python
>>> into([], (1, 2, 3))  # cast lists, tuples, sets
[1, 2, 3]

>>> into(nd.array(), [1, 2, 3])
nd.array([1, 2, 3], type="strided * int32")

>>> into([], nd.array([1, 2, 3]))  # do you remember how to do this?
[1, 2, 3]

>>> into(nd.array(), blaze.array([1, 2, 3])) # and this?
nd.array([1, 2, 3], type="strided * int32")

>>> into([], blaze.array([1, 2, 3]))  # this doesn't even have a clear implementation yet
[1, 2, 3]
```

Generally `into` calls upon functions like `nd.as_py`, `blaze.datadescriptors.as_py.ddesc`, and `list`.  It's challenging to remember all of these routes for us.  I don't expect users to be able to navigate this either.  The `into` function is a single place to put all of our magic.

`into` is a multiply dispatched function.  

The first argument is an example of the kind of thing you want.  E.g. `[]` means I want a list, `nd.array()` means I want a DyND array.  This sort of depends on there either being an instance handy or on a simple empty constructor  (Note that `blaze.array(0)` is the closest that we have in blaze.)

The second argument is your data.