Optimize router HandlerInvoker construction and lookup

Before this change routers created a HandlerInvoker for every request.
With this change, each route's HandlerInvoker is created once and
cached in its own lazy val.

We can use the cached HandlerInvoker to cache route information such
as Java reflection info and request tags. That lets us remove the
ConcurrentHashMap that was previously used to cache Java reflection
info.

These changes improves both Scala and Java performance, but Java
performance improves the most.

To implement the change, we change all the implicits that we
previously used for creating HandlerInvokers into implicits for
creating HandlerInvokerFactories. HandlerInvokerFactories are used
to create the HandlerInvokerFactory for each route.

We need to use a hack to implicitly resolve the correct
HandlerInvokerFactory.

Before, HandlerInvokers were implicitly resolved while a request was
being handled. That meant that the correct implicit HandlerInvoker
could be found by calling the controller method with the request
parameters.

Now, we can't call the controller method, since we want to create a
HandlerInvokerFactories even when we're not handling a request, so
we can't call the controller method with the request parameters.

What we do instead is *pretend* to call the controller method in a
call-by-name thunk, but never actually call that thunk.

It's a bit hacky, but it works. Maybe in the future we could use
macros to directly get the return type of the controller method.