Merge branch 'hkraemer-filtersrv-object-refactoring' of github.com:Tetha/grafana into Tetha-hkraemer-filtersrv-object-refactoring

Add seconds as a new axis formatter

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