Modified metricKeys to handle multiple graphite sources.

This wasn't all too hard to change, I mostly changed the
single http get to multiple http gets, one for each data
source of type graphite.

It's still not a good idea to call this on the web
frontend, since the whole thing was working for about
20 - 30 minutes when I clicked it, so I'm not
committing my changes to settings.js or the view itself.
Extracted multi-graphite query function, fixed loadRecursive

The new function in metricKeys generalizes what my loadAll
from the previous commit did, it takes a request and a
callback. The request is executed on each graphite installation
and the callback is executed for each result. This makes
implementing loadAll and loadRecursive almost as simple as
it was.
Quote timeseries names to be able to have special character such as @ in a seriename.
Quote timeseries names to be able to have special character such as @ in a seriename.
Merge branch 'master' of github.com:Tetha/grafana
Moved dashboard keybinding setup to own service.

The goal is to split up the situation between the dashboard
controller and the current dashboard service. I want to be
able to use the routing in order to select various dashboard
controllers, so I can extend the current scripting
mechanism by implementing new dashboard controllers.

However, to do this in a non-insane way, I need to move as
much functionality as possible into services, so the individual
controllers just need to throw the right set of services
together and add a bit of loading logic.
Added vim swp files to gitignore
Changed filterSrv singleton into object in scope.

This rework isn't entirely complete here, I haven't
checked the tests yet and I didn't really test anything
furthermore yet, so bear with this commit breaking things.

Besides that, the goal of this commit was to rework the
filterSrv singleton into a factory, so we move the filterSrv
instance around via the scope. This should be a better solution
than the current situation, because services shouldn't contain
model data - the scope should.
This will eventually straighten out control flow between dashboard,
filters and so on, and allow us to leverage angularJS mechanics more.
The latter has already started, since I could rework a bit of the
existing event infrastructure to watches on times.
Warnings in dash.js
Warnings in graphiteTarget.js
Warnings in dashboardKeybindings.js
Warnings in filterSrv
Renamed most filter-related things in filterSrv to template.

After all, we are using the function "template" to apply some
data we pull from the URL or other situations in order to call
a function called template. Hence, filtering doesn't make sense
as a term here.
Fixed init-test.

Mostly renames, new init semantic and I forgot to call
updateTemplateParams in addTemplateParameter
Fixed (filter->template)OptionSelected test

- small misunderstanding on my part, fixed the API in the filterSrv back
- renames to match my renames
- init script has to be called or fundefined things happen
Fixed timerange unparsed

 - had to call init with the dashboard mock, since this checks
   dashboard.refresh (need to look at that sometime)
Fixed timerange parsed = true test

 - had to call init with dashboard mock
Fixed setTime should disable refresh test

 - init with dashboard mock
Fixed last test + a mistake in other tests setup

 - filterSrv expects the parameter to init to be the actual
   dashboard object (I'll depend on that later on), so
   I had to pass dashboard.current in there, instead of
   dashboard
 - in the last test, the problem was exactly that again.
Moved init calls to setup method