SDK / exoplayer

A step towards supporting SegmentTemplate style MPDs.

Why: This was a bad initial choice. Manifests typically define bandwidth in
bits/sec. If you divide by 8 then you're throwing away information due to
rounding. Unfortunately it turns out that SegmentTemplate based manifests
require you to be able to recall the bitrate exactly (because it's substituted
in during segment URL construction).

Medium term: We should consider converting all our bandwidth estimation
over to bits/sec as well.

Note1: Also changed Period id to be a string, to match the mpd spec.
Note2: Made small optimization in FormatEvaluator to not consider discarding
the first chunk (durationBeforeThisSegmentUs will always be negative, and even
in the error case where it's not, removing the first thunk should be an error).

- Support parsing of moov atoms contained within each chunk.
- Also do a small cleanup to WebM parser.

- Allow the content type of an adaptation set to be inferred
from the mimeTypes of the contained representations.
- Ensure the contained mimeTypes are consistent with one
another, and with the adaptation set.

Ref: Issue #2

Ref: Issue #2

This change also fixes issue #5

- Add support for parsing avc3 boxes.
- Make workaround for signed sample offsets in trun files always enabled.
- Generalize remaining workaround into a flag, to make it easy to add additional workarounds going forward without changing the API.
- Fix DataSourceStream bug where read wouldn't return -1 having fully read segment whose spec length was unbounded.

This can help custom ChunkSource implementations to act on
this information. For example an adaptive implementation may
choose to blacklist a problematic format if loads of that
format keep failing.

AudioTrack time will go out of sync if the decodeOnly flag
is set of arbitrary samples (as opposed to just those following
a seek). It's a pretty obscure case and it would be weird for
anyone to do it, but we should be robust against it anyway.

1. Fix SimpleCache startReadWrite asymmetry. Allow more concurrency.

- startReadWrite does not have the concept of a read lock. Once
  a cached span is returned, the caller can do whatever it likes
  for as long as it wants to. This allows a read to be performed
  in parallel with a write that starts after it.
- If there's an ongoing write, startReadWrite will block even if
  the return operation will be a read. So there's a weird asymmetry
  where reads can happen in parallel with writes, but only if the
  reads were started first.
- This CL removes the asymmetry, by allowing a read to start even
  if the write lock is held.
- Note that the reader needs to be prepared for the thing it's
  reading to disappear, but this was already the case, and will
  always be the case since the reader will need to handle disk
  read failures anyway.

2. Add isCached method.