BUG: Fix DataFrame.from_records w/ normal ndarray.
I haven't looked at the `from_records` code before, which is why I'm spending all this time laying out a relatively minor change. Previously, was causing a TypeError about None not being iterable when arr.dtype.names was None. Now goes to 'last ditch' parsing instead.

This was the original test case (that dates back, in one form or another, to at least 2010), looked like this:

``` python
self.assertRaises(Exception, DataFrame.from_records, np.zeros((2, 3)))
```

Problem is that the actual Exception was a `TypeError: None is not iterable`-style exception, not something internal to the code.  I changed this so now an `ndarray` that isn't structured (i.e., has `arr.dtype.names is None`) is treated separately from the structured ndarrays (so it goes into the general case 'last ditch' verison).

Now it basically produces the same thing as passing the array to the DataFrame constructor:

``` python
arr2 = np.zeros((2,3))
tm.assert_frame_equal(DataFrame.from_records(arr2), DataFrame(arr2))
```

looks good

this is basically a call to main constructor

ot: there is an issue out there for te reverse
eg main constructor should dispatch to from_records if either an ndarray has dtype.names or the dtype is a compound type
 okay - let's push that to a separate PR though.
 agrees just fyi
 Well, this is the kind of thing that surfaces up when you clean up the Exception testing code (plus, it's a lot easier now that you can use `assertRaises` and `assertRaisesRegexp` as contextmanagers...makes it much easier to read).
