Before this CL, windows (or tabs, panels, etc.) created by
chrome.windows.create API form a relationship that is almost,
but not quite, like an opener relationship:

1. Unlike in a true opener relationship, the 2 frames (opener and
   openee) can find each other, but only if they are still in the same
   process.  For example, if only 1 frame navigates cross-process,
   then the frames won't be able to find each other (for a specific
   example please see https://crbug.com/713888#c5).

2. Unlike in a true opener relationship, window.opener is not set
   (and consequently cannot be navigated by the openee).


After this CL, chrome.windows.create API forms a true opener
relationship *iff* the new parameter - setSelfAsOpener is used.
Otherwise, the newly opened window is created in a separate browsing
instance.  This is required for later restricting named frame lookup
to the current browsing instance (see https://crbug.com/718489).

The CL establishes a true opener relationship, by having
extensions::WindowsCreateFunction::Run pass an opener (a
RenderFrameHost*) into chrome::NavigateParams, rather than using
|force_new_process_for_new_contents| field which this CL removes.


This CL tweaks ExtensionApiTest.WindowsCreateVsBrowsingInstance test
so that:

- The test is closer to what the hangouts extension does
  (it navigates both windows to the same web origin and *then* attempts
  to lookup one window from the other).  Without this modification, the
  test would NOT have caught the hangouts extension regression that was
  almost introduced by https://crrev.com/2873503002).

- The test verifies the opener relationship (i.e. |window.opener|,
  findability via |window.open|, SiteInstance::IsRelatedSiteInstance)
  rather than accidental, indirect manifestations of having an opener
  relationship (i.e. being in the same process or site instance).


Relevant automated tests:
- Tweaked test:
  - ExtensionApiTest.WindowsCreateVsSiteInstance
    (the window.open part passes before and after this CL; the
     window.opener part + the IsRelatedSiteInstance part only pass after
     this CL)
- Other tests:
  - AppBackgroundPageApiTest.Basic
    (hosted app -> background page can violate browsing instance; tests
     handling of mapping of web urls [full url, not just origin] to
     extensions)
  - CtrlClickShouldEndUpInNewProcessTest.* tests
    (tests for behavior that used to depend on the removed
     |force_new_process_for_new_contents| field).

I have also verified that the Hangouts extension (current prod version
- 2017.1019.418.1) works fine before and after this CL (i.e. I have
verified that this CL doesn't regress https://crbug.com/597750).

Bug: 713888
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Test: See above.
Change-Id: If23ac7b72256bfcd695fc4bc3759a5bd73f4812f
Reviewed-on: https://chromium-review.googlesource.com/758801


Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516081}