Refactor api

Here are some of my ideas around refactoring how InfluxDB's API works. The key learning here is that people have been using string columns like tags and it leads to bad performance.

My goal here is to make that the default and to expose an API that is more purpose built around the metrics/time series use case as opposed to the more general purpose SQL.

Please comment on the individual lines of [influx_api_v2.md](https://github.com/influxdb/influxdb/blob/refactor-api/influx_api_v2.md) for focused feedback. Or leave comments in the thread for more general thoughts.

I'm also very interested in hearing about specific use cases. Have I captured everything here? What have I left out? I know this can't encompass everything, but my hope is that it creates a clean foundation that we can easily expand upon.

@jvshahid, @toddboom, @benbjohnson, @dgnorton, @otoolep: please to review.
> Like graphite. If you have dataCenter and host in that order: host isn't even a tag that exists until you drill down into dataCenter and a specific value for it.

this is not really accurate.  yes the tree navigation is probably the most commonly used one, but graphite also has an api endpoint that just returns *all* metric keys at once (`/metrics/index.json`), without giving it any prefix to restrict the output, so if you just get that list you can also see that `host` exists in your example.  There's also a search field in the composer UI where you can just type a host value (without a prefix to drill down by DC first) and it should also return the matching metrics, but not a lot of people use this afaik (not me).

anyway I think we can't discuss implementation pros/cons and tradeoffs if we don't know how they would be implemented.  you're talking about how things are represented to the user but the implementation could be either.  For example, influxdb <=0.8.* only has a set of series names, and yet you can use influxdb as a backend for graphite because it builds the tree structure on the fly by looking at the series names. boom we now have "hierarchy"

I'm ok with discussing this further but I think that requires discussing actual differentiating implementation details.
would hierarchical tags vs regular tags be implemented differently in terms of on-disk or in-memory structures? how so? then we can talk about pros/cons/tradeoffs.