WIP: Configuration Updates

Tasks:
- [x] Restructure configuration file
- [x] Allow loading of external files into conf files
- [x] Merge several conf files inside the configurator
- [x] First implementation of a configuration interface

Byproducts:
- A little notifier


----------------------------
#### Restructuring
Conf files now have a much more sensible format (and are finally tested!). The JSON object of configuration file is now separated into 5 sections.
1. main
2. navbar
3. plugins
4. retrievers
5. resources

The names speak mostly for themselves.
Important: When main declares plugins, or plugins themselves declare retrievers, they now have to do it in an Array of Strings (check the staging config files for examples). These variables act as something like variables. The actual configuration of these plugins happens inside of the plugins object.
The same goes for resources. Example:
```
"retrievers": {
  "treebankRetriever": {
    "resource": "perseids"
  }
},
"resources": {
  "perseids" {
    // resource configuration
  }
}
```
The treebankRetriever declares his resource as a string that acts like a variable. The resource itself is configured in the resources object. This allows for reusability of resources and retrievers/savers.

---------------------------
#### External files
Can be loaded by the inclusion of a `fileUrl` property that includes the path of an external file as string.
A proper load order is guaranteed (the application starts only after all configuration files have been retrieved), even if external files are nested, i.e. an external file contains another reference to an external file, which contains yet another.
It's a heavily commented feature, check out `main_ctrl.controller.js` and `configurator.service.js`

-------------------------
#### Merging configuration files

As discussed recently with @balmas, there are different levels of configuration. On the admin level we might define routes or distinct parts of the application and only allow user customization for several aspects of the configuration.
This will happen by using two (or more) configuration files. It's the `configurator` service's job to merge these files on run time, so that the application has all information to initialize itself.
Merging is already working - specs are present. So far no real-life example has been implemented.

One caveat to watch out for: If a second user config file also loads other external files, we have to guarantee the (asynchronous) loading of these files as well. Will deal with that soon, the code to handle it is already there.

Some added complexity will enter here in the future. Configuration might only be completed during the loading of a state, as loaded documents themselves might contain information about used configuration.
This should be easily possible. The main config file will setup the retrievers, after the documents have been loaded, configuration of plugins will be completed, before the application is finally fully intialized. This might be out of scope for the near future, as documents currently do not contain such information, but this will come sooner or later.

--------------------------
#### The configuration interface

Can be accessed through `app/#/conf_editor/:conf_file`, where `:conf_file` is is optional and would preload a local conf file into the editor.

A file to play around can be accessed through `app/#/conf_editor/to_edit`.

The whole interface is still very edgy and generally not very user-friendly - but it's working.
All main sections are present - and still need work.

An example of a plugin specific configuration is given for the `morph` plugin. Subsequent work on this will happen in separate Pull Requests soon.

-----------------------
#### Notifier

A very simplistic notifier service was done during the process of creating the conf interface.
It's included in the navbar and can be activated by adding `notifier: true` to the navbar configuration.
Will grow in the future.