ENH: add pandas.hdfstore suppport


includes some other commits to make testing clean
- https://github.com/jreback/into/commit/82a6546ee5c6465a851601873f00ff05109a3c0c is in another PR already
- https://github.com/jreback/into/commit/836d5caaf2e3189882a53df343a18a785672c3a2 should be cherry-picked

- Added into support to include chunking / column selection / reading and writing

the use of uri's in resource that need a hierarchical disambiguation
based on priority and the raising of ``NotImplementedError`` by matches
that do not wish to be a resource for that particular uri

IOW. a higher-priority uri matches (e.g. .h5), but the data is
actually PyTables, so HDFStore 'passes' on the processing. PyTables
is next in the chain so it will then process.

Note that a uri can be more fully-disambiguated via a head element
The default is ``hdfstore`` (this only matters for writing), reading
is unambiguous.

e.g.

```
....../file.h5 -> hdfstore
hdfstore://....../file.hdf5|h5 -> hdfstore
pytables://....../file.hdf5|h5 -> pytables
h5py://........../file.hdf5|h5 -> h5py
```
The issue isn't adding dependencies, it's ensuring that future developers are comfortable with the codebase.  I'm hesitant about pytest because I'm unfamiliar with it and so I see it as increasing my maintenance burden.  If py.test is well established then this view is somewhat ego-centric, however if py.test isn't widely understood by the general community then I think that writing tests in this style reduces the development pool considerably.  In many cases I see context managers as a standard built-in solution that does many of these same things and is more widely understood.

Another example is `toolz`.  I find writing lispy toolz code very helpful.  In some cases I'd even like to write in Hy.  Even though these things are comfortable and productive for me I limit their use when more traditional solutions are also applicable with marginal cost.  I view the `pytest_yield_fixture - context manager` difference in much the same light.  It's not established enough in the community to warrant requiring future developers to understand it unless it alleviates substantial development burden.

So by my logic successful arguments to defend the use of pytest would be

1.  It's an established standard that the vast majority of developers likely to work on `into` understand
2.  The alternative is sufficiently unwieldy that we should adopt it anyway.

I don't yet buy 2.  As evidence I think that the h5py test suite solves the same kinds of problems without significantly more code writing.  I also think that it's understandable by a broader population of developers.