demux_mkv: use normal index data structure even for incomplete files

Incomplete files don't have a valid index, because the index is usually
located near the end of a file. In this case, an index is created on the
fly during demuxing, or when seeks are done.

This used a completely different code path, which leads to unnecessary
complications and code duplication. Use the normal index data structure
instead. The seeking code at the end of seek_creating_index() (in this
commit renamed to create_index_until()) is removed. The normal seek code
does the same thing instead.
demux_mkv: simplify cluster reading code

The end positions of the current cluster and block were managed by
tracking their size and how much of them were read, instead of just
using the absolute end positions.

I'm not sure about the reasons why this code was originally written
this way. One obvious concern is reading from pipes and such, but the
stream layers hides this. stream_tell(s) works even when reading from
pipes. It's also a fast call, and doesn't involve the stream
implementation or syscalls. Keeping track of the cluster/block end is
simpler and there's no reason why this wouldn't work.
demux_mkv: fix streaming clusters

Matroska files prepared for streaming have clusters with unknown size.
These files are pretty rare, see e.g. test4.mkv from the official
Matroska test file collection.
demux_mkv: factor block reading

The code for reading block data was duplicated. Move it into a function.

Instead of returning on error (possibly due to corrupt data) and
signalling EOF, continue by trying to find the next block. This makes
error handling slightly simpler too, because you don't have to care
about freeing the current block. We could still signal EOF in this case,
but trying to resync sounds better for dealing with corrupted files.
demux_mkv: move BlockGroup reading code to a separate function

Somehow this was setup such that a BlockGroup can be incrementally
read (at least in theory). This makes no sense, as BlockGroup can
contain only one Block (despite its name). There's no need to read
this incrementally, and makes the code confusing for no gain.

Read all the BlockGroup sub-elements with a single function call,
without keeping global state for BlockGroup parsing.
demux_mkv: split reading blocks and reading packets

Move most code from demux_mkv_fill_buffer() to read_next_block(). The
former is supposed to read raw blocks, while ..fill_buffer() reads
blocks and turns them into packets.
demux_mkv: move Block header parsing code

Move parts of the Block element parsing to read_block(). This way
read_block() can return block time and track information in
struct block_info.
demux_mkv: fix seeking with index generation

Relative seeks backwards didn't work too well with incomplete files, or
other files that are missing the seek index. The problem was that the
on-the-fly seek index generation simply added cluster positions as seek
entries. While this is perfectly fine, the seek code had no information
about the location of video key frames. For example, a 5 second long
cluster can have only 1 video key frame, which is located 4 seconds into
the cluster. Seeking backwards by one second while still located in the
same cluster would select this cluster as seek target again. Decoding
would resume with the key frame, giving the impression that seeking is
"stuck" at this frame.

Make the generated index aware of key frame and track information, so
that video can always be seeked in an idea way. This also uses the
normal block parsing code for indexing the clusters, instead of the
suspicious looking special code. (This code didn't parse the Matroska
elements correctly, but was fine for files with normal structure. Files
with corrupted clusters or clusters formatted for streaming were not
handled properly.)

Skipping is now quite a bit slower (takes about twice as long as
before), but it removes the special cased skipping code, and it's still
much faster (at least twice as fast) than libavformat. It needs to do
more I/O (no more skipping entire clusters, all data is read), and has
more CPU usage (more data needs to be parsed).
demux_mkv: remove redundant check
demux_mkv: static allocation for lace sizes buffer

Don't use malloc() for that. The max. possible size for this array is
still a bit too large for the stack (8k), so put it into to demuxer
context.
demux_mkv: use a bounded buffer for block data

Should help avoiding out-of-bounds reads.
demux_mkv: check block malloc() result
demux_mkv: there can be 256 laces

The lace number is stored with an offset of 1, so the maximum number
of laces is 255+1=256.
demux_mkv: get rid of the duplicated lace case labels

Also change the extracting of the lace type bitfield from flags to
make it more apparent that the value range is 0-3.
demux_mkv: verify laces separately, and in all cases
demux_mkv: simplify handle_block() logic a bit