### 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 an issue that matches the one I want to file, without success.

Ref #19447

### Issue Details

* **Electron Version:**
  * 9.0.0-beta.24
* **Operating System:**
  * macOS 10.15, Windows 10
* **Last Known Working Electron version:**
  * none

### Expected Behavior
`e.sender` object received from an extension background page should have `webPreferences` and `session` initialized. It looks like `options` in `api::WebContents` constructor don't get initialized properly for an extension background page.

### Actual Behavior
`e.sender` object doesn't have `session` and `e.sender.getWebPreferences()` returns `null`.

### To Reproduce
https://github.com/sentialx/electron-quick-start/tree/extensions/no-session

Just run it and you will see something like this:
![image](https://user-images.githubusercontent.com/11065386/82097607-82994400-9703-11ea-8291-0eb987d8aca0.png)

### Additional Information
This is a real blocker for anyone who would want to provide own `chrome` APIs in background pages initialized from different sessions.
shell/browser/api/electron_api_web_contents.cc
IPC_BEGIN_MESSAGE_MAP(Ws, message)
    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}
 There are three ways of destroying a ws:
 1. call ws.destroy();
 2. garbage collection;
 3. user closes the window of ws;
 4. the embedder detaches the frame.
 For webview only #4 will happen, for BrowserWindow both #1 and #3 may
 happen. The #2 should never happen for ws, because webview is
 managed by GuestViewManager, and BrowserWindow's ws is managed
 by api::BrowserWindow.
 For #1, the destructor will do the cleanup work and we only need to make
 sure "destroyed" event is emitted. For #3, the content::Ws will
 be destroyed on close, and WsDestroyed would be called for it, so
 we need to make sure the api::Ws is also deleted.
 For #4, the Ws will be destroyed by embedder.
void Ws::WsDestroyed() {
   Cleanup relationships with other parts.
  RemoveFromWeakMap();
   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 Ws is released by the embedder
   frame, and we need to clear the reference to the memory.
  if (IsGuest() && managed_ontents()) {
    managed_ontents()->ReleaseWs();