created hierarchy interface

this allows retrieving a subtree of the concept hierarchy

the following parameters are to be supported:
* root (required): ID (i.e. "origin") of the root concept
* dir: direction of the hierarchy - either "down" or "up"
* depth: number of hierarchy levels to be included
* siblings: if true, siblings of each node will be included even if they
  are not part of the hierarchy

siblings support has yet to be implemented

NB:
* this partly duplicates the existing hierarchical_concepts resource
* requests of this kind are potentially expensive, due to the large
  number of database queries required (one per concept as we recursively
  traverse the hierarchy) - however, that seems inevitable without
  significant adjustments to the data model
ensured root concept is included in hierarchy

this seems slightly inelegant, as it breaks encapsulation by creating
the same data structure as returned by `populate_hierarchy` - not sure
whether there's a more elegant way though
fixed minor concept hierarchy issues, as revealed by tests
expanded test coverage for concept hierarchy
turned concept hierarchy's root from query into path parameter

before:

    GET /hierarchy?root=foo;...

after:

    GET /hierarchy/foo?...
improved parameter validation, expanded test coverage

plus removed debugging remnants
added support for siblings in concept hierarchy

note that this can be very expensive

some optimization might still be possible by eagerly loading relation
targets
updated concepts hierarchy tests with now-mandatory language parameter
added RDF representations

more recursion, yay!

note that we're creating temporary relation instances while traversing
the tree being passed from the controller

tests compare string blocks to avoid having to parse RDF