Add plumbing for allowing the renderer to intercept and cancel redirects before

      they are sent.

A good portion of this CL is to support the new UI test.

The IPC to notify the renderer of a redirect now includes a ResponseInfo struct
allowing WebURLLoaderImpl to provide detailed response info (including response
headers) to WebKit.  This isn't strictly necessary, but I thought I'd include
this to make the code more future proof.

A cross origin restriction is added to SyncResourceHandler::OnRequestRedirected
that mimics the code in WebCore/platform/network/cf/ResourceHandleCFNet.cpp.
This is most unfortunate, and I filed a bug at bugs.webkit.org about the
similar duplication of logic in WebCore.

There seemed to be enough code paths leading to request cancellation at the
ResourceDispatcher level that I couldn't easily ensure that a request only gets
cancelled once.  So, I added an is_cancelled flag to record if it is not
necessary to send a ViewHostMsg_CancelRequest IPC.  This avoids some warnings
in the ResourceDispatcherHost.

To support my UI test, I needed to change URLRequestMockHttpJob to know how to
serve redirects.  I moved URLRequestHttpJob::IsRedirectResponse to its base
class, URLRequestJob so that the implementation could be shared.  This revealed
a minor bug in URLRequest.  We were never resetting response_info_ upon
following a redirect.  I added this code consolidated similar code from
URLRequest::Redirect and URLRequest::RestartWithJob into a new PrepareToRestart
method.

To support my UI test, I added a &quothit count&quot field to URLRequestFilter, and I
added an associated automation IPC to query the value.  The test was a bit
challenging to write because there is no way to tell the difference from JS.
Before and after, it appears to JS as though the cross-origin redirect failed.
However, the server can see the extra redirect request.  So, I simply record
the number of hits against URLs of the form http://mock.http/foo, and use that
to observe if a