Rework Client Action Handlers to 'Dispatch Interceptors'

This pull request covers the following:
1. Client Action Handlers are now following the naming convention of 'Interceptors', in order to hopefully remove any confusion around the server side ActionHandler's which have a very different task conceptually.
2. Starts on supporting REST dispatch interceptors defined by the API resources of any particular RestAction. RestAction's are generated classes and hence cannot be indexed by class type.
3. Separates the required classes into their respective packages (rpc/rest).

Hopefully I haven't forgotten anything here. This has been tested and works fine so far but there will be room for improvement of course as my time is somewhat limited at the moment. This rework has been implemented by me to meet a business need and hopefully the concept make sense to you guys too and will prove useful for anyone else using the REST Dispatch. If there is anything that needs changing please let me know and I'll improve it asap.

Future Prospects:
* Improve the InterceptorContext used by the RestInterceptor's. This will eventually change to account for a more robust set of definitions (plus it's currently somewhat incomplete).
* Support transcendent context definitions `/items/*`.

TODO:
* [x] Revise the javadocs.
* [x] Write some tests.

Will update as I go.
I'm pretty sure all the registry logic could be simplified (less boilerplate) with [GinMultibinder](http://google-gin.googlecode.com/svn/branches/2.1.x/javadoc/com/google/gwt/inject/client/multibindings/GinMultibinder.html), then you'd have something like this:
```
         install(new RestDispatchAsyncModule.Builder()
             .dispatchHooks(AppRestDispatchHooks.class)
            .addInterceptor(CarDeleteInterceptor.class)
            .addInterceptor(ManufacturerDeleteInterceptor.class)
            .build());
```