Remove Pipeline::has_{audio,video}_ members.

Remove Pipeline::has_{audio,video}_ members.

[Ami GONE FROM CHROMIUM, 2012-08-30 07:09:10]

Last plane-flavored CL before getting on a plane, I promise!

https://chromiumcodereview.appspot.com/10915003/diff/1/media/base/pipeline.cc
File media/base/pipeline.cc (right):

https://chromiumcodereview.appspot.com/10915003/diff/1/media/base/pipeline.cc...
media/base/pipeline.cc:671: NOTREACHED() << "Unexpected state: " << state_;
Added b/c otherwise the control structures in this function make even less
sense.

[scherkus (not reviewing), 2012-08-30 07:23:42]

let's talk more tomorrow but the reason I didn't do this in
http://codereview.chromium.org/10837206 was because audio/video_renderer_
variables are currently set/used on a single thread and this would break that

[Ami GONE FROM CHROMIUM, 2012-09-02 09:40:27]

(per offline convo w/ scherkus)

This change explicates the existing races (e.g. between has_audio_ being set and
audio_renderer_ being dropped, and so on).

But actually it's crazy that we even have Has{Audio,Video}()!  Instead, the
presence of each type of track should be reported as part of Pipeline's
end-of-initialization callback.  Probably best to have a separate
enum TrackType { AUDIO, VIDEO };
typedef base::Callback<void(TrackType)> HaveTrackCB;
passed to Pipeline::Start, which is used to report the presence of tracks to
WMPI, which will cache as needed to report has{Audio,Video}() to webkit later.

Closing this CL in favor of that approach.