Adds parser recovery for type parameters and type arguments

Adds parser recovery for type parameters and type arguments

Note that this un-does part of a previous change for parser recovery.
   http://codereview.chromium.org/8576007/

The resulting AST seems more complete in the test cases I came up
with.

Committed: https://code.google.com/p/dart/source/detail?r=6364

[zundel, 2012-04-08 07:48:58]

https://chromiumcodereview.appspot.com/10021017/diff/2001/compiler/java/com/g...
File compiler/java/com/google/dart/compiler/parser/DartParser.java (right):

https://chromiumcodereview.appspot.com/10021017/diff/2001/compiler/java/com/g...
compiler/java/com/google/dart/compiler/parser/DartParser.java:265: while
(!EOS()) {
This looks worse than it really is.  I just removed the try { from around this
block of code....

https://chromiumcodereview.appspot.com/10021017/diff/2001/compiler/java/com/g...
compiler/java/com/google/dart/compiler/parser/DartParser.java:292: if (node !=
null) {
Updated the recovery in this section.

[scheglov, 2012-04-09 17:20:46]

lgtm

[zundel, 2012-04-10 12:20:16]

When I ran the unit tests, the editor test failed and the AST looked terrible. 
The error recovery not advancing the token while looking for an identifier was
creating ASTs like this:

original

typedef < F  )

AST that was created looked something like:

typedef < F extends F> (F F)

This was because the stream is no longer advancing the token state.  I went in
and created an 'error' identifier node, like we have for some statements.  This
error node looks like an identifier and fills in the AST.

@Steve, I updated the completion engine so that all the unit tests pass, but I
added some calls to 'visitChildren()' which weren't there before. I don't quite
understand the visitor in the Completion engine as it doesn't seem to recurse
much - I might have messed things up.

I am sorry but I accidentally deleted the original patch set during self-review.

[scheglov, 2012-04-10 13:39:14]

still LGTM

[messick, 2012-04-10 14:38:18]

LGTM

The visitors defined in CompletionEngine shouldn't recurse. Prior to firing them
up another visitor is used to determine the node for which completion is
requested. No need for you to change anything; I'm going to have to integrate
these changes with the mods I'm making to completion so I'll take care of it.