- 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.

 - init with dashboard mock

 - had to call init with dashboard mock

 - had to call init with the dashboard mock, since this checks
   dashboard.refresh (need to look at that sometime)

- 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

Mostly renames, new init semantic and I forgot to call
updateTemplateParams in addTemplateParameter

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.

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.

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 nanosecond y-scale formatting

fixes #226

Improvement to series toggling, CTRL+MouseClick on series name will now hide all others (Closes #350)

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.

Change InfluxDB SQL generation template to wrap column names in quoutes

Since column names can contain dots or dashes, which will give syntax errors from InfluxDB API, unless wrapped in quoutes

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.

Fixes to filters and the 'All' option. It now never uses '*' as value, but all options in a {node1, node2, node3} expression (Closes #228, Closes #359)

Fixed an exception when adding a graphite function.