Replace FFmpegDemuxer thread per element with base::TaskScheduler.

I don't think we need to keep starting a thread per <audio> or
<video> element anymore. Instead we can use a shared pool that
only spins up a new thread when needed.

This change switches FFmpegDemuxer from creating its own thread
to using base::TaskScheduler for executing blocking network reads.
The TaskScheduler API is perfectly suited for our use case and
required little changes.

Doing this required some changes to our BlockingUrlProtocol to
make it safe to access after FFmpegDemuxer and potentially the
DataSource have been destroyed.

This should reduce the number of out of threads crashes we see on
a fairly regular basis.

BUG=61293
TEST=existing tests all pass, no slowdown noticed on pages like gfycat.com

Review-Url: https://codereview.chromium.org/2710133003
Cr-Commit-Position: refs/heads/master@{#453470}
12 files changed