~30x routing speedup

EDIT: Travis build fails, details below. Summary: discussion is needed. The tests pass on my machine, but an unpublished dependency has been added.

Hello there :) I'll start with the juicy details.

```
BEFORE:
RoutePerformanceTest.doBenchmark: [measured 10 out of 15 rounds, threads: 1 (sequential)]
 round: 2.77 [+- 0.24], round.block: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], \
GC.calls: 223, GC.time: 0.22, time.total: 40.99, time.warmup: 13.32, time.bench: 27.67
```

```
AFTER:
RoutePerformanceTest.doBenchmark: [measured 10 out of 15 rounds, threads: 1 (sequential)]
 round: 0.10 [+- 0.03], round.block: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], \
GC.calls: 6, GC.time: 0.01, time.total: 1.90, time.warmup: 0.86, time.bench: 1.04
```

What used to take **27.67** seonds, now takes **1.04** seconds.

In short, the speed is obtained by using a trie-like data structure that has logarithmic performance, instead of a linear array check where at worst every route has to be checked against the incoming URL. In the new code, method and accept is only checked against what's available for the matched path. I expect this to result in good real-world performance. It's pretty common to have lots of overlapping routes (/people, /people/:id, /people/:id/tasks, ...), but for each route, a pretty low amount of methods and accepts. Methods lookup is done through a hash map, but accept headers is stil linear since it uses the old code for walking a set of possible content types. But I doubt it's common to have more than 10 or so accepted types.

The built-in router has been replaced with https://github.com/augustl/path-travel-agent. **Note:** path-travel-agent is not published to maven central yet, as it's pretty new and absolutely not battle proven.

RouteEntry has been removed. Hopefully this wasn't considered a public API. I haven't investigated the possibility of keeping it around, but I have a hunch it's a lot of work, since it was pretty internal to the way the old router worked. SimpleRouteMatcher retains it's API despite the complete reworking of its internals.

I'm expecting this pull request to need some work  before it's accepted, so I decided to include the benchmark code in it, even though it's probably not relevant for inclusion in spark code base.

Finally, I just want to add that replacing the routing and getting the tests to pass was a pretty easy task. The routing code in spark is sensible and well organized :)