Constituents update

Implements a so far read-only environment for @jonathanrobie's constituent trees

![jr_text_tree](https://cloud.githubusercontent.com/assets/2204549/5187438/70231188-74cd-11e4-896c-f183849f6105.png)

Two main features/refactors had to be done to enable this:

- While creating the `ConstituentTreebankRetriever`, the regular `TreebankRetriever` was also heavily refactored. It's something like a model class for other retrievers and therefore needs to be solid. Code-wise both of these retrievers are looking quite decent now and are very readable.
- The code in the `dependencyTree` directive needed to be re-used for the `constituencyTree` directive. The main code that drives these trees is still kinda hard to get into - but it's extracted to a newable factory now. One could argue that a controller would be the thing to do here, but it's also OK to solve it this way I guess. This `Tree` factory exposes a couple of important functions - which can be overridden by an implementing direcitve - just what the `constituencyTree` directive is doing, which e.g. doesn't need `edgeLabels`, so it overrides the function dealing with them to do nothing.

Also provides a first real implementation of #500 (complex colorization schemes for morphology) in the `jr.json` configuration file.

When developing locally you can take a look at an example of these constituent trees here: http://localhost:8081/app/#/jr?doc=luke_example_large


There'd be more work involved to make this really interactive and editable - but this is not a top priority right now.
A couple of minor tweakings are in order if this is going to be used as well, mostly styling-wise, but we're almost there. Another minor bug concerns complex morph color schemes on startup of the application, which are displayed correctly in the tree at first. A separate PR will deal with this.

#450 should be fixed with this as well. Check cb65055.



Fixes #450, fixes #502