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
made utility methods private

because @mrreynolds is a Java fanboi in disguise
improved error handling for concepts hierarchy
added HTTP caching for concepts hierarchy

review appreciated
added Last-Modified header for concepts hierarchy caching

improves chances that clients take advantage of caching

in the process, simplified database query
Merge branch 'master' into getHierarchy
Merge branch 'master' into getHierarchy
fixed race condition in tests

apparently `update_attributes` does not *reliably* work for
`updated_at`, whereas `update_attribute` seems to work just fine
Merge branch 'master' into getHierarchy
removed unnecessary variable

this was a remnant from earlier experiements
simplified hierarchy processing

whether this is actually more readable, I'm not really sure
Merge branch 'master' into getHierarchy