Grid layout - layout changes on the fly - refactor general settings handling

We are finally making a step towards a grid layout.

We using `angular-gridster` for this, a forked version to be exact to keep our dependencies limited (fe9a202).

This is still very much in an experimental phase - a follow-up issue will deal with what has to be done to make  it really effective.

Work on it also lead to a couple of refactors regarding layouts in general and the `globalSettings` service.

- Layouts are fully animated now, which just looks awesome when the application starts.
- `globalSettings` can be dynamically defined now and are also streamlined a bit. When the grid is active, additional settings are present for example.
- Settings handling on a plugin level is also much nicer now and handling through a couple of distinct directives (`pluginSettings`, `pluginSetting`). The `plugin` directive can specify if settings should be included in a plugin template (through the attribute `with-setting`) or if a user wants to customize their position and look. The regular sidepanel layout for example still shows them at the top of their respective tab, while the grid layout hides them in a specific section which is also used to drag grid items around. As settings are now passed programmatically it's theoretically also possible that the presence of a plugin A adds a setting to a plugin B.
- Settings objects are generated by a new global helper variable `arethusaClasses` (aliased to `aC`, similar to `arethusaUtil` and `aU`). We've had to deal with small helper classes that we wanted to use across angular modules before. While this breaks the general dependency injection pattern it's probably OK to have a couple of `Arethusa` specific global variables around. This will eventually lead to some refactors in already existing code, where we had to duplicate our helper classes up until now.


One additional important thing is the an event that is fired when all plugins are loaded called `pluginsLoaded`. This makes it easier for us to keep track of when we are done pulling in additional dependencies.