Revert of Revert of Remove threading from RendererGpuVideoAcceleratorFactories

Revert of Revert of Remove threading from RendererGpuVideoAcceleratorFactories (https://codereview.chromium.org/145103004/)

Reason for revert:
Reverting the revert as it did not fix the failures.

Original issue's description:
> Revert of Remove threading from RendererGpuVideoAcceleratorFactories (https://codereview.chromium.org/27420004/)
> 
> Reason for revert:
> Sorry, it looks like you broke the Win 7 Tests (dbg)(2) bot. http://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%282%29/builds/19785
> 
> Original issue's description:
> > This change removes all the threading considerations from
> > GpuVideoAcceleratorFactories (and its implementation,
> > RendererGpuVideoAcceleratorFactories).  Most notably, it removes Abort() and
> > associated functions and state.  And with the removal of Abort() and friends,
> > we can also remove its Clone() interface.
> > 
> > All of the previously abortable operations on the RGVAF (with the exception of
> > ReadPixels()) can be made non-abortable, with no functional difference, due to
> > the way the users of RGVAF function.  These three users are
> > WebMediaPlayerImpl/GpuVideoDecoder, RTCVideoDecoder, and RTCVideoEncoder, and
> > they can be made non-abortable because:
> > 
> > WebMediaPlayerImpl/GpuVideoDecoder:
> > * Abort() is called from WebMediaPlayerImpl::Destroy().  It has no effect, as:
> >   * All the RGVAF entry points are called from the the RGVAF message loop
> >     from GpuVideoDecoder (except for ReadPixels()), so the Abort() has no
> >     effect on them.
> > 
> > RTCVideoDecoder:
> > * Abort() is called from RTCVideoDecoder::WillDestroyCurrentMessageLoop() for
> >   the RGVAF message loop.  It has no effect, as:
> >   * Amost all the RGVAF entry points are called from the RGVAF message loop
> >     (except for ReadPixels()), so Abort() has no effect on them.
> >   * The other exception is CreateVideoDecodeAccelerator(), which is called from
> >     RTC's main thread.  But as the Abort() is called from
> >     WillDestroyCurrentMessageLoop() for the RGVAF message loop itself, it is
> >     guaranteed to occur after any tasks posted to the RGVAF message loop by
> >     CreateVideoDecodeAccelerator() has completed, and so the Abort() has no
> >     effect.
> > 
> > RTCVideoEncoder:
> > * Abort() is called from RTCVideoDecoder::Release().  It has no effect, as:
> >   * All the RGVAF entry points are called from the RGVAF message loop.
> > 
> > The only functional difference remaining is that making ReadPixels()
> > non-abortable.  This is preferable, as as long as a completed video accelerator
> > texture is available, it should be readable.  We also specify that all calls to
> > ReadPixels must be made on the RGVAF message loop, like all other entry points,
> > and leave it up to the users of ReadPixels() to handle thread trampolining if
> > necessary.
> > 
> > BUG=306333
> > TEST=local build, run on CrOS snow; build, run unittests on desktop Linux
> > 
> > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=247480
> 
> TBR=fischman@chromium.org,wuchengli@chromium.org,jamesr@chromium.org,jam@chromium.org,hshi@chromium.org,sheu@chromium.org
> NOTREECHECKS=true
> NOTRY=true
> BUG=306333
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=247655

TBR=fischman@chromium.org,wuchengli@chromium.org,jamesr@chromium.org,jam@chromium.org,hshi@chromium.org,sheu@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=306333
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=247662

[Adam Rice, 2014-01-29 08:24:55]

Created Revert of Revert of Remove threading from
RendererGpuVideoAcceleratorFactories

[commit-bot: I haz the power, 2014-01-29 08:25:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ricea@chromium.org/135393004/1

[commit-bot: I haz the power, 2014-01-29 08:25:37]

Change committed as 247662

[Adam Rice, 2014-01-29 11:10:53]

A revert of this CL has been created in
https://codereview.chromium.org/144303004/ by ricea@chromium.org.

The reason for reverting is: It turned out the reverting the patchset was
effective after all, so I am reverting the revert of the revert..