initial progress towards graphite support

not meant for merging, but just for discussion, feedback, etc.
this just parses `graphite("graphite-expr")` in the config. right now there's only 1 arg, the expression.

i numbered the things i'ld like responses to.

1) i presume i should add a second arg to control timeframe to collect(i.e. `from=-2minutes`), which i presume is also what the `sduration` ("2m") does for opentsdb?  I checked http://bosun.org/configuration.html#opentsdb-query-functions but don't really understand what startduration and enddurations are, are they the start and end boundaries between which to collect data? (why are they called duration?) and endduration empty means "now", right?
2) I'm also not sure if i'm somehow supposed to enforce a certain datapoint interval, or is whatever graphite returns ok? (depending on series and timeframe the returned data might be secondly, 10-secondly, minutely, hourly, etc, based on how the user configured graphite).  should this be passed on as an argument via `graphite()`? (i hope not)

next step: actually having this query graphite, figuring out in which shape i should feed the timeseries data from graphite into bosun (3) any insights on this anyone?), and 4) figuring out whether or not it's a problem that there's no tags, ever, when using graphite (empty map of tags).
something that graphite does is if you query for "foo.bar.*" and it returns a series "foo.bar.web1", "foo.bar.web2", "foo.bar.web3" i could probably somehow automatically compute tags node3=web1, node3=web2, node3=web3, but i'm not sure if this is needed, and it might be much effort if i need to add "tag awareness" in several places i didn't expect.

also 5) i hope it won't be a problem that i'm not using scollector and not feeding any data into scollector? i just want bosun to query graphite and use the data it returns
I believe we should be forgiving towards the user, and also towards graphite.  i don't want to enforce any strictness at this point around what the returned format should be, i rather have the code just make the best out of whatever it can do and actually display the parsed tags, allowing the user still to fine tune further if he/she wants things to "look nicer", but the values as is should be about as useful.