fix: Fix compositor recycling when creating new BrowserView

In electron#20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also electron#19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView

shell/browser/api/atom_api_web_contents.cc

@@ -399,7 +399,10 @@ WebContents::WebContents(v8::Isolate* isolate,
   // Whether to enable DevTools.
   options.Get("devTools", &enable_devtools_);
 
-  bool initially_shown = true;
+  // BrowserViews are not attached to a window so they should start off as
+  // hidden. This is also important for compositor recycling. See:
+  // https://github.com/electron/electron/pull/21372
+  bool initially_shown = type_ != Type::BROWSER_VIEW;
   options.Get(options::kShow, &initially_shown);
 
   // Obtain the session.