Handle recovery on "timestamp-looking" lines in the WebVTT parser

When a line with a "-->" is encountered as part of cue-text, in the
header part or after a previous error (i.e. during "bad cue" processing).
The parser is supposed to break out of the current state and try to parse
the "-->" line as being the start of a new cue.

Updated testcases:

PASS -> FAIL
tc006, tc007 and tc011 (Tested the old behavior where "-->" was
allowed/ignored, and blank lines were required to start a new cue.)

FAIL -> PASS
opera/track/webvtt/parsing subtests nulls, header-timings, header-space,
header-tab and arrows
opera/interfaces/TextTrackCue/vertical.html

TEST=media/track/track-webvtt-tc031-cue-recovery.html
TEST=media/track/track-webvtt-tc032-degenerate-cues.html
BUG=305317

Review URL: https://codereview.chromium.org/75273002

git-svn-id: svn://svn.chromium.org/blink/trunk@162210 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Move CustomFilterMeshGenerator from core/platform/... to platform/...

BUG=303332

Review URL: https://codereview.chromium.org/69593002

git-svn-id: svn://svn.chromium.org/blink/trunk@162211 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Fix resetTransform() bug on paths. In order to reset the path transform, we should apply the forward CTM, since the cumulative path transform is the inverted CTM.

BUG=319541

Review URL: https://codereview.chromium.org/68713005

git-svn-id: svn://svn.chromium.org/blink/trunk@162212 bbb929c8-8fbe-4397-9dbb-9b2b20218538