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.
InfluxDB Filters: added function to generate filter list.
InfluxDB Filters: added filter to queries.
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.
url decode metric names #327
Updated version to 1.5.4
updated changelog
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