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.
Great that we are thinking about this -- I believe this to be a major issue with the systems being built today. In my experience the only way to run large systems in production is to measure an enormous number of parameters of that system. This is because Operations and Development can never be sure what will be the root cause of an outage or other type failure, so must measure many parameters. But in large systems the problem of then finding the metric becomes unwieldy. A successful system must make it easy to find the metrics contained within.

One other approach is to include free-text search of metrics, auto-completion etc. Another way Operations teams deal with this issue is to adhere to a strict naming scheme for metrics, making it easier to "guess" a metric name.

Discoverability is a big deal. I'm really glad we're thinking about it.