Implement active wheel fling transfer via WebCompositorInputHandlerClient

Implement active wheel fling transfer via WebCompositorInputHandlerClient

There are cases where we'll process a GestureFlingStart event on the
compositor thread, initiate a wheel fling, and then later determine that
we can't process the rest of the animation on the compositor thread. One
example of where this could happen is if the page registers a mousewheel
JS event listener while the fling is in progress. In this case, we need
to transfer the animation to the WebView to process so it can generate
the correct events.

This implements the transfer as a call out via the
WebCompositorInputHandlerClient. I think this is a reasonable place to
put the interface, since it's intimately related with the input
processing stream.

BUG=don't have handy, but there is one
TEST=wheel fling on CrOS should work with --enable-threaded-compositing

[jamesr, 2012-03-21 14:38:30]

https://chromiumcodereview.appspot.com/9817001/diff/2001/content/renderer/gpu...
File content/renderer/gpu/compositor_thread.cc (right):

https://chromiumcodereview.appspot.com/9817001/diff/2001/content/renderer/gpu...
content/renderer/gpu/compositor_thread.cc:92: // We will always destroy the
CompositorWrapper through
note: I haven't fully convinced myself that this is true. a careful analysis of
the lifetimes here would be really helpful

[jamesr, 2012-03-21 18:05:17]

RenderViewImpl supports WeakPtr<>, so if we can get a hold of one of those then
the shutdown path should be easy. I don't know of any way to do that but it
_should_ be easy to do given a routing_id.  We could also probably do it as part
of the input handler initialization, since that's always initiated from a
RenderView.

I think someone else should review this, I wrote some of it so I'm not a good
objective viewer.