Get rid of PreParserIdentifier.

Get rid of PreParserIdentifier.

To do scoping properly (declare variables into scopes, check for error such as
redeclaration and strong mode use before declaration), PreParser needs to keep
track of identifiers for real. For this, PreParserIdentifier is not sufficient,
but PreParser needs to start using AstRawString*s instead.

This is the first of a series of changes - this just replaces PreParserIdentifier
with AstRawString*. The follow up changes will then declare these identifiers in
scopes (for that, PreParserExpression needs to somehow - TBD how exactly - store
multiple identifiers in case it's an arrow function parameter list).

BUG=

[marja, 2015-02-12 16:10:33]

marja@chromium.org changed reviewers:
+ rossberg@chromium.org

[marja, 2015-02-12 16:10:34]

rossberg, ptal.

I'm going to run some perf tests before landing, w/ parser shell and the perf
try bots. (That is, next week.)

[marja, 2015-02-12 16:31:34]

Meh, parse time regresses by 20% w/ this change for my "big script with lazy
functions" sample file. The perf trybots are running.

Otoh, if we need to do the identifier / scope dance, it's going to regress perf
to some extent for sure.

[marja, 2015-02-12 16:41:11]

... alright, benchmarks such as jsbench and octane seem unaffected though.
Dunno.

[rossberg, 2015-02-16 12:23:45]

LGTM

It might be worth introducing a

  typedef const AstRawString Identifier;

somewhere appropriate.

Do you have an idea why it is regressing so badly on the artificial benchmark?

[marja, 2015-02-16 13:05:31]

I think the regression is because PreParser also now needs to maintain this
table of AstStrings, find the stuff in the table, update the table, etc, because
it now needs to know which identifier the given identifier is, not just that
it's an identifier. So it's simply just doing more work than before and the
regression is unsurprising from that point of view.

[marja, 2015-02-16 13:21:44]

... some moar perf numbers. I made my test js file extremely lazy by wrapping it
inside function superlazy() { .. }. There the regression is even worse, 30%. So,
this will make PreParser 30% slower (130 ms vs. 100 ms). Though, it's still much
faster than Parser (220 ms). But I wonder at what point will adding features to
PreParser make it as slow as Parser.

An upside is, though, that this will eventually allow lazy parsing of inner
funcs, which should give some speedup on realistic web pages...

[marja, 2015-02-16 14:36:07]

Numbers:

Actually, looks like there are some consistent regressions:

Emscripten/NBodyJava 3%
JetStream/code-first-load 5%
JetStream/code-multi-load 5%

(Weird, code load shows no regression, and code-first-load and code-multi-load
should be the same, no?)

Also, JSBench/JSBenchFacebook *does* regress by 3%, I must have mis-checked that
previously.