Adjust the requested step size based on the width of the graph.

requested in #252 

On each refresh, the width of a widget is checked. This value is used to scale the requested step size in the query to Prometheus.

The current "normalizing value" is 800, which corresponds to 800px. This is totally up for debate. Using 800 right now changes the number of data points received per series in one of our large 4-column dashboards from **258 points per series to 88 points per series**.

@matthiasr, could you check to see if this improves your performance?

The corollary to this is for large graphs, ADDITIONAL data is requested. a graph filling the full width of the screen is getting twice as many data points per time series. This looks great, but might lead to strain on Prometheus. Will have to talk with @juliusv to see how confident he is in the new version that'll be dropping any day now :)

## larger graph
current resolution:
![image](https://cloud.githubusercontent.com/assets/1398104/5538473/c28b3f52-8ab4-11e4-9494-8b3ec6478ce0.png)

increased resolution owing to this pr:
![image](https://cloud.githubusercontent.com/assets/1398104/5538477/d728718c-8ab4-11e4-825d-0c619377e8b9.png)

## smaller graph
current resolution:
![image](https://cloud.githubusercontent.com/assets/1398104/5538508/4b36e1da-8ab5-11e4-852b-6e318b6d1270.png)

decreased resolution owing to this pr:
![image](https://cloud.githubusercontent.com/assets/1398104/5538494/30b2c95a-8ab5-11e4-8f8f-b8857856fa1c.png)



We could (and I will make that change now).

As it stands a large portion of the refresher needs to be re-written for the graphing library extraction. We currently bind `$scope` into this function via a closure, and then freely pull of whatever properties we want from that, which will have to be undone.