(reland)

Remove threading from GpuVideoAcceleratorFactories

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.

This is a reland with one change after a revert of a revert of a revert of a
revert of a revert of r247480.  (WE NEED TO GO DEEPER)

BUG=306333
TEST=local build, run on CrOS snow; build, run unittests on desktop Linux
TBR=wuchengli@chromium.org, fischman@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@250672 0039d316-1c4b-4281-b951-d872f2087c98
Added --extended-response to put additional information into PTR responces.
Shortened service name.
Added AAAA response.

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@250673 0039d316-1c4b-4281-b951-d872f2087c98
Blink roll 166943:166948

http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=166944:166948&mode=html
TBR=
BUG=

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@250674 0039d316-1c4b-4281-b951-d872f2087c98
Update .DEPS.git

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@250675 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 250675