<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
<!-- Is your feature request related to a problem? Please add a clear and concise description of what the problem is. -->
The `BrowserView` is much like `BrowserWindow`, but it cannot be used as a "window" for the `new-window` event.

Imagine a tabbed layout with several `BrowserView`s, much like the regular browser window. The `webPreferences.nativeWindowOpen` is enabled.

*Use-case 1:* The page inside one `BrowserView` tries to open a new window via `window.open()`. There's no way to handle `new-window` and create a new `BrowserView` such that the `window.opener` JavaScript property refers to its opener.

*Use-case 2:* A `<form target="_blank" method="POST">` inside `BrowserView` is submitted. A new `BrowserView` can be created and its `WebContents` `loadURL()` method can be used to navigate using `POST` method. But AFAIK there's no way to know what exactly `postData` that form was going to POST.

It works fine if the `new-window` is default-prevented and a new `BrowserWindow` is created with the `options.webContents` as a constructor option. But it is ignored for a `BrowserView`

### Proposed Solution
<!-- Describe the solution you'd like in a clear and concise manner -->
- Allow setting `webContents` in a `BrowserView` constructor options.
- Allow `BrowserView` to be a `e.newGuest` in a default-prevented `new-window` event.

### Alternatives Considered
<!-- A clear and concise description of any alternative solutions or features you've considered. -->

### Additional Information
<!-- Add any other context about the problem here. -->

shell/browser/api/electron_api_web_contents.cc
sure "destroyed" event is emitted. For #3, the content::WebContents will
 be destroyed on close, and WebContentsDestroyed would be called for it, so
 we need to make sure the api::WebContents is also deleted.
 For #4, the WebContents will be destroyed by embedder.
void WebContents::WebContentsDestroyed() {
   Give chance for guest delegate to cleanup its observers
   since the native class is only destroyed in the next tick.
  if (guest_delegate_)
    guest_delegate_->WillDestroy();
   Cleanup relationships with other parts.
   We can not call Destroy here because we need to call Emit first, but we
   also do not want any method to be used, so just mark as destroyed here.
  MarkDestroyed();
  Emit("destroyed");
   For guest view based on OOPIF, the WebContents is released by the embedder
   frame, and we need to clear the reference to the memory.
  if (IsGuest() && inspectable_ontents_) {
    inspectable_ontents_->ReleaseWebContents();
    ResetManagedWebContents(false);
  }
   Destroy the native class in next tick.
  base::ThreadTaskRunnerHandle::Get()->PostTask(
      FROM_HERE, base::BindOnce(
                     [](base::WeakPtr<WebContents> wc) {
                       if (wc)
                         delete wc.get();
                     },
                     GetWeakPtr()));
}
void WebContents::NavigationEntryCommitted(