* Various features

1. Nested routes don't need to be wrapped in an extra vector but may be (for backwards compatibility)
2. Prefixes are now "first-class", possible on arbitrary levels of nesting by simply starting a vector with ["/sub" ["/next" :action ...] ...]. Consequently, such prefix paths can also be parameterized so that all contained actions can dispatch these params.
3. Actions that are specified as symbols have their namespaces required (in case they are not loaded yet) 
4. Idents must be keywords, are checked for uniqueness at "route compilation time" (e. g. when build-routes is invoked).
5. Multiple idents for one route are possible if specified in a set. This is generally not something one should need to use, however given that in Caribou each page has one "slug" and is limited to one request-method, it became common to specify multiple pages with different slugs but the same path. Given that slugs are used for reverse routing and the request-method is not relevant in that regard,  I could not find any reasons to implement individual idents for  request-method/action pairs. ~~This feature allows for Caribou code to first `group-by` routes on one nesting level by their path and then base one Caribou spec on each group with all idents of the group so that reverse-routing still works with the Caribou slugs.~~ (Such conversion now happens automatically)
6. Serve a 405 (method not allowed) when a route is specified but not a method. A custom handler for that case may be passed to `router`.

Backwards issues
- Everything except `build-routes`, `reverse-routes`, `router` is not API exposed and thus declared as private.
- ~~All request-methods supported by one path must now come in one route-spec with said path (e. g. multiple route-specs with the same path and only one method each won't work anymore).~~

Rewrite:
Many functionality has been rewritten. In most cases this was a requirement due to the functionality desired above. I find the current dispatch of the route DSL tolerable, however the code could certainly be simplified with `core.match`.