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
```
>  I can trivially setup and teardown a database with the exact scope that I want. I claim that Joe Schmo can come in and easily read most fixture code because of the way py.test makes you write fixtures. With nose I can have setup and teardown functions that are 10000 lines apart. With py.test, I must write the setup and teardown as one function, which forces you to think about it up front.

I'm not comparing py.test to `unittest` style setup/teardown functions (these are indeed terrible and difficult to compose).  These also have nothing to do with `nose`.  I'm comparing fixtures to context managers, which you write equivalently and have the same setup-teardown semantics.

> The same context manager repeated across N functions are significantly more annoying IMO than having a single fixture, with N functions that all take a single argument (that fixture)

That's a valid concern, typing `with mycontextmangager(arguments)` is more typing than just adding the fixture to the test function signature.

>  That way you're 100% that each function is using the exact same thing. It's very easy to copypaste something without 100% fidelity

I'm not sure that that's always what I want.  I find that I generally write fewer context managers than you guys but that those context managers are more configurable / require more logic in each function.

Regarding Joe Schmoe programmer, is there evidence that he deals with fixtures well?  Are there many successful projects that have gone down this route before?  What's the temperature like just within Continuum for example?  Do most people incorporate pytest into their projects?  I would feel more comfortable establishing this as a standard if I saw more people using it.

I'm more ok with Blaze being somewhat space-age.  I'd like to keep into really approachable as a sort of gateway project.