Move browser-to-renderer opener plumbing to frame routing IDs.

Move browser-to-renderer opener plumbing to frame routing IDs.

This CL allows a new RenderView to set its main frame's opener to any
frame, rather than a top-level frame.  I.e., it is now possible to use
window.opener to refer to a cross-process subframe.

Summary of changes:

* The ViewMsg_New IPC now passes the opener's frame ID rather than
  view ID.  RenderView::Initialize resolves this into the opener's
  WebFrame.

* The flow of opener routing IDs from RFHM::InitRenderView to
  RenderViewHostImpl::CreateRenderView (which sends the IPC) is moved
  from view to frame IDs.

* The passing of opener routing IDs from CreateOpenerProxies, etc.,
  into RFHM::InitRenderView is removed.  Instead, InitRenderView now
  looks up the proper opener frame routing ID itself.  This is because
  (1) the previous flow would complicate implementing opener updates,
  which would allow subframes to have openers and FrameTrees to have
  more than one opener to traverse, and (2) previous plumbing missed
  some cases (e.g., creating swapped-out RVs via
  CreateRenderFrameProxy or CreateProxiesForSiteInstance), and fixing
  this would add more complexity.

* There are paths where the opener chain is intentionally suppressed
  from a new RenderView, for example for <webview>: see
  WCI::CreateSwappedOutRenderView and EnsureOpenerProxiesExist.  This
  is now supported via an explicit flag which is passed into
  InitRenderView rather than passing around MSG_ROUTING_NONE for the
  opener's routing ID.

BUG=225940, 304341

Review URL: https://codereview.chromium.org/1202593002

Cr-Commit-Position: refs/heads/master@{#337995}