Be more tolerant of bad VTT

[bloomtom]

Have you read the FAQ and checked for duplicate open issues?
Yes

Is your feature request related to a problem? Please describe.
Small defects in a vtt file can cause the entire thing to be dropped. Specifically, linefeeds in cue text and multiple linefeeds between a cue timestamp and its text. Trying to parse such a file in the demo player results in an error this.data_ is undefined.

I have my ever-useful two second clip demo prepared with such a vtt file. It's the Italian language.
Demo Link

The content of that vtt file is

WEBVTT

00:00.000 --> 00:00.500
<b>Alla tua destra puoi vedere...

|...ma pensa...</b>

00:00.500 --> 00:01.000

Visible

00:01.000 --> 00:02.000
Visible

Describe the solution you'd like
Technically a vtt file structured in this way is not compliant with the standard, yet there is much of it around due to ffmpeg. If you have extraneous linefeeds in an srt or ass file, and you ask ffmpeg to turn it into a vtt, it'll make a file that looks like the above. It would be nice if Shaka could render such files.

Describe alternatives you've considered
I have a patch in for review on the ffmpeg mailing list, but even if future files are compliant, that doesn't fix the issue for vtt files which have already been created.

Additional context
This is a feature request because I'm unsure if strict parsing was intended by the original implementer. Although other players display such malformed vtt files, they are technically not obliged to do so.

[joeyparrish]

I'm open to this, assuming it doesn't over-complicate the parser. We would need some additional tests to cover the new functionality, but it could be as easy as adjusting some regexes in the VTT parser.

Are you interested in building a PR for this?

[bloomtom]

Yes. I'll take a look at handling this one as well. Thanks for the input.

[didof]

Is this PR going to be accepted?