SDK / exoplayer

It looks like for the case of self-contained media segments,
it's possible to get stuck without failure in the case that
the load fails having loaded less than the length of the init
data.

Issue: #35

Issue: #31

Since we have a Format class as well, it's very confusing that
FormatHolder actually holds a MediaFormat. I think it's quite
likely that Format will need promoting into the root package as
part of the HLS work, which will make this even more confusing
(although it is possible that for HLS we'll define yet another
Format class, if it turns out we need significantly different
fields).

Note - I deliberately avoided renaming the formatHolder
args/params, because they're not particularly ambiguous and
because it introduces some ugly line breaks.

- Bring back requirement for the first video frame to be rendered
  before isReady returns true, *unless* we've deduced that the
  upstream source is serving multiple renderers.
- Ditto for requiring that the audio track has some buffered data.

- cache ref didn't work because it referred to a private variable
  (which isn't documented) from a public interface definition
  (which is). Meaning the Javadoc generator was trying to link
  to documentation that didn't exist.

The equals check we perform needs to ignore the max dimensions.
This tended to work in practice because formats would be the
same object, but in the case where different format objects
are used, things can break.

Issue: #4

- Add constants class. Currently housing a single lonely variable,
which is used generally throughout the library, and so no longer
nicely fits into a specific class.

- Rename a few other constants to add clear units.

- Made minor tweak to ExoPlayer documentation.

1. Use ints rather than longs.
2. Remove some counters that dont seem hugely useful.
3. Replace use of volatile with explicit method calls that
   cause a memory barrier. This is a lot more efficient than
   using volatile because it can be invoked only once per
   doSomeWork.

- Make MediaCodecTrackRenderer.isReady more permissive.
  This largely fixes #21
- Bring WebmExtractor closer to FragmentedMp4Extractor.
  The two will probably be placed under a common interface
  fairly soon, which will allow significant code
  deduplication.

* Remove concept of being prepared by simply reporting if format
and/or cues are known.
* Allow replacement of format and/or cues later in the stream.
* Initialization and index segments can be parsed independently
of one another but must be in order due to internal WebM dependencies.
* Let seekTo() work even when cues are unknown.

Thanks!

Add missing files.

Merge 1.0.11 to master

Misc Notes:
- Removed content type filters because some of third parties
  don't set content type.

This paves the way for SegmentTemplate and SegmentList based
mpds, which will implement DashSegmentIndex directly rather than
parsing an index from the media stream.

- Define DashSegmentIndex.
- Make use of DashSegmentIndex in chunk sources.
- Define an implementation of DashSegmentIndex that wraps a SegmentIndex.
- Add method that will allow Representations to return a DashSegmentIndex
  directly in the future.
- Add support for non-contiguous index and initialization data in media streams.
  For the Webm case this isn't enabled yet due to extractor limitations.
- Removed ability to fetch multiple chunks. This functionality does not extend
  properly to SegmentList and SegmentTemplate variants of DASH.

A step towards supporting SegmentTemplate style MPDs.