Implement new navigationRequested / newViewRequested APIs

[Chris Coulson]

I've never really been all that happy with the way that the current API works - where navigationRequested is used as part of the path for opening a new webview as well as current-tab navigations. This was only really implemented like this because of an issue with not being able to make a policy decision in newViewRequested (ie, you currently can't decide to not create a webview in newViewRequested), but the implementation is making it difficult to improve the API.

What I want is something like this:

WebView.navigationRequested2:
- Emitted for navigation requests in the current view.
- Provides url / userGesture properties.
- Emitted twice per navigation - PreStart and PreCommit, allowing embedders to make a decision on the original request URL and the final pre-commit URL after redirects. We are able to do this with bug 1470268.
- Provides an API for transferring the navigation to another webview (not sure if this is possible yet, but I think it is. It would be a nice to have anyway)

WebView.newViewRequested2:
- Emitted before a request starts.
- Provides url / userGesture / disposition / position properties.
- Allows the request to be attached to an already existing WebView (not sure if this is possible yet, as it means discarding the already created WebContents. Although, this is essentially the same as not creating a WebView so if we solve that problem then it should be fine)