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.
a few more notes on metadata:
* step (perhaps even distinguish between forward and rearward step), not only for trends. This has also an impact when interpolating values because you interpolate on the horizontal line (from previous or next value) and don't need to intersect with the line between datapoints. This is probably also linked to the Gauge concept.
--> little illustration of step modes: http://zedgraph.dariowiz.com/images/3/37/Smoothchart.png
* descriptor, a human readable description of what the timeseries represents
* zero and span/range: used for trends to indicate the expected range of the data. Useful when defining a trend with fixed axes instead of dynamically adjusting axes that hide the absolute magnitude of the values.
* a text field to indicate for example a source address can be useful to do a reverse lookup: based on the timeseries metadata, find which sensor at which modbus address it represents. Very useful when debugging connection or configuration issues. Using tags for this seems a little inappropriate.