Stop checking hasTriggers in RenderLayerCompositor::updateAcceleratedCompositingSettings.

In practice, the only time this would ever return false was when
m_webView->allowsAcceleratedCompositing would return false,
which in turn only happened when compositor creation failed.
It turns out that now that GTK linux is gone, we never call
WebViewImpl::didExitCompositingMode anymore because we always
succeed in creating a compositing OutputSurface (we fallback
to a software compositing OutputSurface instead of returning
null). So, the only codepath that hits this now is unittests
and possibly <webview> and android webview printing because
they use a WebViewClient that returns a null layerTreeView.

Instead of keeping track of whether compositor creating failed,
just disable accelerated compositing. This has the same effect
since we will never try to reenable accelerated compositing.

Now that the compositing triggers no longer depend on WebViewImpl,
we can move the logic into CompositingReasonFinder.

Review URL: https://codereview.chromium.org/242123002

git-svn-id: svn://svn.chromium.org/blink/trunk@171913 bbb929c8-8fbe-4397-9dbb-9b2b20218538