Interceptors mechanism (fixes #6)

Changes REST invocation flow from simple `RestClientMethodInterceptor` -> `RestTemplateInvoker` to much more flexible and extensible interceptor/handler architecture. Basically each REST call is wrapped in `RestInvocation` value object and passed to first `RestInvocationHandler` (with highest priority). Each handler can either process invocation or pass is further (`invocation.proceed()`, see `LoggingHandler`). Last handler must handle the request, typically this will be `RestTemplateInvoker` (added automatically to the end of handlers chain).

Handlers are auto-discovered in application context and sorted using `Ordered` interface. This architecture makes it very easy to implement a lot of custom functionality:

* logging (built-in)
* profiling (built-in, measuring time)
* caching
* unmarshalling/deserializing
* transparent retry mechanism
* modifying HTTP headers, parameters, etc. (see `UserAgentHandler`), (see #8)
* wrapping calls, e.g. in Hystrix
* using arbitrary HTTP client
* implementing `@Async` (see #7)
* handling arbitrary annotations (see #10)

And a lot more. It's basically specialized AOP inside the library.
Why do we need those dependencies defined explicitly?