ENH: SQL multiindex support
Further work on #6292.

This adds:
- fixes the `columns` argument (wasn't passed) + added test for that
- adds multi-index support in `to_sql`, by just using `reset_index` on the frame (+ tests)
- adds multi-index support in read_table (+ tests)

I think you should raise if the multi index doesn't have named levels
I do that in hdfstore - it can work but it's relying in the level naming scheme and so a bit unexpected
better to force the user to name levels
 @jreback Only for multi-index when it has no names? And for a single index leave it? (so 'index' is used in that case)
 @jreback the tests fail on `assertListEqual` not known on Travis, but this did work on my local machine. Any idea?
 I use assertEqual for lists - though assertLisstEqual sounds better
 And the strange thing is, it only broke on Travis for one of the builds, while the sql tests are at least also tested in one of the other builds.
 Aha, assertListEqual is new in Python 2.7. Just use assertEqual then?
 look at HDFStore.Table.validate_mulitindex

I do allow none levels (but then convert them back when reading)

only problem was levels overlapping with column names
 Pushed new version with slightly other approach.

But some questions on the API:
- should we allow a MultiIndex without level names? (suggested by @jreback to raise and force user to provide `index_labels`). Now they get the default names `level_0`, `level_1`, ... like in `reset_index`.
- if we detect columns with names like `level_0` or `index`, should we set them as index when reading the data? (personally I would say we leave this to the user, as we can never be fully sure)

@mangecoeur @hayd 
 @jorisvandenbossche 

since SQL cannot really store meta data, its a bit non-trivial to automatically figure out the `index_col` whether it is `index` or `level_n`. Bigger problem is that a user will not know how to specify the index columns in the first place.

Maybe best not to allow non-named levels at all?
 @mangecoeur Would you have some time to review this? (as you wrote most of this code)
 Since there isn't more feedback, I am going to merge this to not hold up further PRs. But off course, if there still feedback, glad to hear it! It can always be adapted afterwards.

@jreback I am going to take the same way as `reset_index`, so allowing non-named index levels. That seems the most consistent with rest of pandas. And also not trying to guess what the index was when reading the data back in from sql.

The only problem I still have is the legacy mode. I didn't add multi-index support to legacy `to_sql`, so the support to write the index is only half baked. It is also new functionality since 0.13.1, so actually an API change for the legacy mode. But I will open a seperate issue for that.
 @jorisvandenbossche all fine

FYI if u reset and get an error I think in HDFStore I raise
that - meaning reset dailies because of duplicate index/columns
 @jreback Ah, yes, good idea, I catched the exception and expanded the error message.
