Merge 170403 - Use a lock to deal with concurrent access to the m_evictedBackings

Merge 170403 - Use a lock to deal with concurrent access to the m_evictedBackings

Use a mutex to deal with concurrent access to the m_evictedBackings
list, instead of passing the list of pointers around.

In ThreadProxy::beginFrame, we unlink all evicted textures, so that
the call to updateLayers will know to re-paint the evicted layers.

In ThreadProxy::scheduleActionCommit, we determine if we can draw now
by checking to see if there exist any linked evicted textures. If there
are none, we can draw what we are in the process of committing.

This assumes that once we get to m_layerTreeHost->willBeginFrame()
in ThreadProxy::beginFrame, the next frame to be commited by
ThreadProxy::scheduleActionCommit be at or after the frame that is
being produced by that call to ThreadProxy::beginFrame.

BUG=158747
TBR=ccameron@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=170635