Remove numpy structured array as data container in Table

This issue is to explore the idea of entirely removing the `np.ndarray` or `np.ma.MaskedArray` structured array object that currently serves as the primary data storage.  This object is referenced as `Table._data` in the code.

The way `Table._data` currently works is that it is essentially the owner of all the table data and the `Column` objects then hold references to the columns in `Table._data` (hereafter just `_data`).  A fair bit of the trickier table code is maintaining that duality when mutable table operations are performed.  When you start trying to integrate other data types as `Columns` it gets very tricky / untenable.

The proposal is to make a `Table` be a collection of `Columns` where the `Column` objects are the primary and independent data owners.  I am hoping that implementation of this will actually result in a net reduction of code and overall simplification of logic.  Some advantages:

- Issues #1833, #1835, and #1839 should all become much easier.  This is a big driver.
- Relatedly, potential for more flexibility to match needs of VOtable and FITS tables (#1964 and #199).  Nested tables and columns with different properties should be much easier.
- Cheap addition / removal of columns.  An idiom that people (@eteq!) apparently like is to create an empty table and then progressively build the table by adding one column at a time.  This is currently very inefficient since the `_data` object needs to be re-built from scratch for each column.
- Columnar access (probably the dominant mode) may be faster because the data values in memory won't be strided.

Issues:

- The `Row` class will need work to replicate the functionality currently handled by `np.void` and `np.mvoid` classes.  There is something weird and magical about those classes I have never entirely understood, so fully replicating them represents a real uncertainty right now.
- It's likely that iterating through a table by rows will be even slower.  Even now there is a lot of Python code running for each row so it's starting out slow.
- Users that are defying convention and using `_data` directly will be out of luck, though we could put in a compatibility property that basically creates the equivalent `ndarray` on request (and issues a warning saying don't use this!).
- The accepted way to create a pure `np.array` from a `Table` will always generate a copy.  Currently it can be a reference.
- The high level table operations are implemented at a low level using pure `ndarray`s.  This will need some work.

Comments / discussion please!

@astrofrog @eteq @embray @mhvk @mdboom 

The use case I had in mind was, for example, ingesting an entire table, row by row, into a function that commits that row to a database for example, though it could be any other function that takes all the row values as some argument, that is:

```python
def some_func(*row):
    # do something with row
```

This can be benchmarked by running
```python
def read_rows():
    for row in t:
        tuple(row)
```

On master this was actually a little slower than I expected, but then I realized that there was no `Row.__iter__` so it had to go through `Row.__getitem__` for each iteration.  So I added to the `Row` class:

```python
def __iter__(self):
    return iter(self._data)
```

and that sped it up significantly.  For a table of 20 columns each of 1000 random floats I got:
```
In [9]: %timeit read_rows()
10 loops, best of 3: 19.9 ms per loop
```

on this branch the same test is giving me:

```
In [13]: %timeit readrows()
1 loops, best of 3: 476 ms per loop
```

Optimizations on master aside, why am I getting such a slower benchmark for this test on your branch, while you're getting something an order of magnitude faster?