Split out CSSParser public API

Split out CSSParser public API

This patch separates the public API of BisonCSSParser from the hundreds
of public methods it exposes. The plan is to build a new parser based on
the css-syntax specification, which will eventually complete replace the
bison-based parser. The functions in this class will do the run-time
switching between the bison parser and the new (unwritten) parser.

For the functions here which are only ever used with a newly instantiated
BisonCSSParser, I've moved instantiation to inside the CSSParser so that
the functions can be static.

This is an updated version of a patch by eseidel from 8 months ago:
https://codereview.chromium.org/112933010/

BUG=330389
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=181825

[Timothy Loh, 2014-09-11 04:23:41]

timloh@chromium.org changed reviewers:
+ alancutter@chromium.org, eseidel@chromium.org, esprehn@chromium.org

[Timothy Loh, 2014-09-11 05:47:02]

I've roughly planned out how I intend to do all of this. I'll start off with
some minor simplifications of the CSSParser API to make it a bit more sane (I
didn't want to do anything complicated in this patch so all the functions
currently just forward to the BisonCSSParser). Then I plan to build a parser
(renaming and extending the MediaQueryTokenizer/etc.) for the whole CSSParser
API. This will all be done behind a disabled runtime flag.

The MediaQueryParser will live alongside the new parser since it only handles
media conditions and we'll call into it where necessary.

The logic from the existing code that'll remain is the CSSPropertyParser and the
fast-path parsing logic for lengths, colors and so on. One of the main concerns
will be getting the CSSPropertyParser working with the new token stream. I
intend to map the new token stream to CSSParserValues until the Bison parser is
removed, as many changes are required in the CSSPropertyParser for it to work
with the new token stream (the main difficulty is that cubic-bezier(), calc(),
etc. are all represented as a single (recursive) CSSParserValue).

I'll of course need to look at performance before flipping the flag. Hopefully
it won't be a concern, even though we will need to have an extra conversion to
CSSParserValues. After the old code is removed, I'll work on removing
CSSParserValue so CSSPropertyParser can operate directly the new tokens.

[eseidel, 2014-09-11 15:55:02]

The CQ bit was checked by eseidel@chromium.org

[eseidel, 2014-09-11 15:55:03]

lgtm

[commit-bot: I haz the power, 2014-09-11 15:56:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/566483002/40001

[commit-bot: I haz the power, 2014-09-11 16:01:31]

Committed patchset #3 (id:40001) as 181825

[jianli, 2014-09-11 18:48:20]

A revert of this CL (patchset #3 id:40001) has been created in
https://codereview.chromium.org/566703002/ by jianli@chromium.org.

The reason for reverting is: Caused compiling errors..

[eseidel, 2014-09-11 19:26:18]

Which compile errors?

This passed the CQ.  The CQ is supposed to be safe.
https://sites.google.com/a/chromium.org/hackability-cy/pillar-1