Using several config files at once & fixes for the contextMenu

Through the function `configurator.shallowMerge()` we can now do a custom merge of two configuration files. (custom as in: reacting properly to Arethusa JSON config markup).

This is already in use and triggered by the `TreebankRetriever`, which watches the `@format` attribute of a treebank document. 

#330 added additional conf info to the `documentStore`. An additional complete config file shall be stored there with the special key `fullFile` (opposed to plugin specific re-configuration, where the key has to correspond to the name of the plugin). The `configurator` knows how to handle this in its `loadAdditionalConf()` function.

The value of the `fullFile` property can either be a string or a fully qualified http url. When it's a string, the default config store of Arethusa is queried for the file (it's deployed at http://services.perseids.org/arethusa-configs as outlined in #330), when it's an url the url itself is queried.

When the request fails, it is just passed over - the application won't break. In the future we want to notify the user - about a successful retrieval of an additional file or about errors. This will come when we make the switch to a better notification system soon. (right now we can only display one notification at a time - as right after an additional conf file has been loaded the "Document loaded" message arrives, we wouldn't be able to see it)

The reasoning behind this: Perseids now only holds a base configuration file (`perseids.json`), which defines all resources as well as general stuff. It's a very comprehensive file that configures pretty much everything. The `@format` attribute of documents then selects a specific configuration for a document - cf. the file for the [Smyth's Grammar config](https://github.com/latin-language-toolkit/arethusa-configs/blob/master/smyth.json), which even overrides the used plugins.

This is a nice way of freeing up backends of specific too many different routes for specific Arethusa configurations - it comes at the price of documents being able to re-configure the application anyway they want, which is both a feature and a problem. We might want to at least specify an additional configuration param in base configuration files, that allows to disable the retrieval of additional configurations - otherwise documents can only be used in a very specific context, which limits their value.

It's an area that will see more work once we read in multiple documents. Right now only one document can add additional configuration - but what happens when several want to do this? As documents are retrieved asynchronously there's not even a load order that could be guaranteed.

There are several other issues: What if I don't want to override a configuration from a second file, but only add to it? Conf files should probably be able to specify what they want to do, which adds of course further complexity to conf files. But it might be worth it in the end.



While doing this a couple of issues with the contextMenu appeared - I am not sure that they were caused by the work of this PR or happened before as well. I think the latter is true.

In any event, this seems to be fixed now. The contextMenu could frequently end up empty - the problem was wrong handling of a scope variable, which couldn't update itself (in the `pluginContextMenu` directive)

The dreaded firefox behaviour upon right click has also been fixed!

The contextMenus were also leaking a bit, by never removing the event handlers added to the `document`. Looks better now.



Closes #335