Reapply "[PH] Disable cross origin paint holding if there was no user activation."

This reverts commit 011f2568aab9a77614d10ad913a18a825ea7d6bb.

Original patch description:
This patch disables paint holding if this is a cross origin navigation
and there was no user activation. This is a safety measure to prevent
sites from continually displaying mismatched URL and content.

With regular user behavior (clicks, etc), the behavior should be
unchanged since this counts as user activation.

Difference from original CL:
The difference is that we post a task to timeout paintholding, which allows embedding to differ and happen further down in the stack.

Details:
The surface eviction happens in this stack
content::DelegatedFrameHost::ResetFallbackToFirstNavigationSurface()
content::RenderWidgetHostImpl::ClearDisplayedGraphics()
content::RenderWidgetHostImpl::ForceFirstFrameAfterNavigationTimeout()
content::RenderFrameHostManager::CommitPendingIfNecessary()
content::RenderFrameHostManager::DidNavigateFrame()
content::Navigator::DidNavigate()

There is a bifurcation in ResetFallbackToFirstNavigationSurface to
decide whether to evict the delegated frame. This decision is based
on whether we have an first local surface id after navigation. On
non-Mac system, this local surface id is set in a stack similar to
the one below:

content::DelegatedFrameHost::EmbedSurface()
content::RenderWidgetHostViewAura::SynchronizeVisualProperties()
content::RenderWidgetHostViewAura::ShowWithVisibility()
content::RenderFrameHostManager::CommitPendingIfNecessary()
content::RenderFrameHostManager::DidNavigateFrame()
content::Navigator::DidNavigate()

Importantly, this happens _before_ we reset fallback, so in typical
cases we avoid eviction of the frame and simply reset its surface.

On Mac, the stack that sets the frame is below:
content::DelegatedFrameHost::EmbedSurface()
content::BrowserCompositorMac::DidNavigate()
content::RenderWidgetHostImpl::DidNavigate()
content::RenderFrameHostImpl::DidCommitNavigation()
...
content::mojom::NavigationClient_CommitNavigation_ForwardToCallback

This call happens _after_ we reset the fallback, so in typical cases
we evict the frame before embedding a new one. This is a cause for
a lot of test failures (and ultimately the reason for the revert).

Because the reset fallback path never happened synchronously with
DidNavigate, it isn't clear at this time whether this poses a problem
in non-test cases. Out of abundance of caution, I propose posting a
(non-delayed) task to remove paint holding. In practice this means
potentially having paintholding in place while the UI thread is busy.
This, however, is still a mitigation for the initial bug, albeit one
that does not have strict guarantees.

R=​creis@chromium.org
Bug: 40942531

Change-Id: Id45d1e2267147da2a6f4351cb95d3d8002d8f7ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5894513
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363640}