Fix support for VisualDiagnosticsOverlay/IWindowOverlay on Android Shell Apps

[drasticactions]

With MAUI Shell Apps on Android, WindowOverlay and VisualDiagnosticOverlay don't work. If you try to hover over the live visual tree in Visual Studio, the elements that should be highlighted are not. If you try and add your own WindowOverlay to an existing window (Which you can do but is not documented anywhere, but trust me when I say that it is!) it does not appear.

This, I believe, is do to the way Shell and Non-Shell apps handle the initial Window startup.

maui/src/Core/src/Platform/Android/Navigation/NavigationRootManager.cs

Lines 123 to 152 in 43b9397

	void SetContentView(IView? view)
	{
	if (view == null)
	{
	if (_viewFragment != null && !FragmentManager.IsDestroyed(_mauiContext.Context))
	{
	FragmentManager
	.BeginTransaction()
	.Remove(_viewFragment)
	.SetReorderingAllowed(true)
	.Commit();
	}
	_viewFragment = null;
	}
	else
	{
	_viewFragment =
	new ElementBasedFragment(
	view,
	_mauiContext!,
	OnWindowContentPlatformViewCreated);
	FragmentManager
	.BeginTransaction()
	.Replace(Resource.Id.navigationlayout_content, _viewFragment)
	.SetReorderingAllowed(true)
	.Commit();
	}
	}

When setting the initial NavigationRootManager for Android, the delegate OnWindowContentPlatformViewCreated gets called when the initial Fragment for the application gets made. This gets called back into the Window Handler code, which invokes the VisualDiagnosticOverlay handler initialization, allowing Window Overlay code to work. For Shell apps though, this code doesn't get fired, the view in SetContent is null.

This is called out in the comment above,

maui/src/Core/src/Platform/Android/Navigation/NavigationRootManager.cs

Lines 79 to 84 in 43b9397

	// if the incoming view is a Drawer Layout then the Drawer Layout
	// will be the root view and internally handle all if its view management
	// this is mainly used for FlyoutView
	//
	// if it's not a drawer layout then we just use our default CoordinatorLayout inside navigationlayout
	// and place the content there

Shell apps handle their fragments through other means. Still, because of this, the RootViewChanged logic in the Window Handler never gets called, meaning the VisualDiagnosticsOverlay code never gets run, meaning overlays won't work. The overlay logic has to be run after the initial views are laid out to be placed on top of the existing views., so there needs to be similar logic in place for shell apps.

I tried putting it inside of the ShellRenderer, after its logic is run and the fragments are switched, that means the views should have been loaded and should be safe for us to call the VisualDiagnosticOverlay logic on the Window to get it to run.

I'm not sure if this is the right thing to do here, but hopefully, this shows the issue at hand for why it's happening.

Fixes #10781

[rachelkang]

interesting, thanks for explaining!

(not reviewing, just here to learn)