UI: Initialize YouTubeAppDock synchronously to fix Qt runloop issues

The YouTubeAppDock uses its own cookie manager and thus requires a
running CEF instance before creating the dock. Unfortunately creation
of the dock itself and launching the associated browser instance are
coupled in the code.

The UI code to restore browser dock states runs _after_ this code and
unfortunately this is also the only way to ensure that if the user
has closed the YouTubeAppDock before that it stays closed on app
launch (the dock needs to exist in the Widget hierarchy for its state
to be restored).

Alas, outside of Windows, InitBrowserPanelSafeBlock uses a separate
local QEventLoop to block the main thread while still allowing UI
events to be processed to launch a CEF instance.

By this point in the code execution, the primary event loop has not
been started yet, so the event loop launched by
InitBrowserPanelSafeBlock temporarily becomes the main application
event loop, which initializes all Widgets, finds no active window
state for the widgets, and thus treats them as "visible", calls the
showEvent method on every browser dock, which thus loads the associated
websites.

The dock state is restored after all that, which leads to each browser
dock being "shown" (even though the main QApplication hasn't even
started yet), the associated sites are running (including audio and
video output) but then hidden again, which leads to surprising audio
output seemingly coming from "nowhere".

All browser docks call the browser initialization methods synchronously,
which has the benefit of not spinning up a premature event loop, and does
not trigger Qt view state changes before all Widgets have been
initialized. Having the YouTubeAppDock behave the same does thus not
negatively impact UX.

UI/window-dock-youtube-app.cpp

@@ -36,6 +36,7 @@ YouTubeAppDock::YouTubeAppDock(const QString &title)
 	  dockBrowser(nullptr),
 	  cookieManager(nullptr)
 {
+	cef->init_browser();
 	OBSBasic::InitBrowserPanelSafeBlock();
 	AddYouTubeAppDock();
 }