Include LineTerminatorSequence in TemplateElement cooked values

The 2013-09-27 draft of the ES6 draft, section 11.8.6, now says "The TV of TemplateCharacter :: LineTerminatorSequence is the TRV of LineTerminatorSequence."

https://code.google.com/p/esprima/issues/detail?id=456
Module export should not treat default as a special case.

https://code.google.com/p/esprima/issues/detail?id=410
As a property name, static should be quoted.

In strict mode, static is a reserved word.

https://code.google.com/p/esprima/issues/detail?id=469
Make arrow function bodies not always strict

This changed in draft 19.

https://code.google.com/p/esprima/issues/detail?id=472
Fix arrow function parameter strictness

Per ES6 Draft 21, section 14.2:

  ArrowFormalParameters:
    ( StrictFormalParameters )

Per 14.1.1:

  StrictFormalParameters : FormalParameters
    It is a Syntax Error if BoundNames of FormalParameters contains any duplicate elements.

  FormalParameters : FormalParameterList
    It is a Syntax Error if IsSimpleParameterList of FormalParameterList is false and BoundNames of FormalParameterList contains any duplicate elements.
    It is a Syntax Error if IsSimpleParameterList of FormalParameterList is false and BoundNames of FormalParameterList contains either ′′eval′′ or ′′arguments′′.

https://code.google.com/p/esprima/issues/detail?id=472
Allow eval and arguments in non-strict mode when IsSimpleParameterList is false

@awbjs is removing this rule from 14.1.1 FormalParameters : FormalParameterList (draft 21):

  It is a Syntax Error if IsSimpleParameterList of FormalParameterList is false and BoundNames of FormalParameterList contains either ′′eval′′ or ′′arguments′′.

https://twitter.com/awbjs/status/401016388279480320

https://code.google.com/p/esprima/issues/detail?id=472
Fix arrow functions in group expressions

These failed to parse:

  (x) => ((y, z) => (x, y, z)) // Error: Line 1: Unexpected token =>
  (x => x) // Error: Line 1: Unexpected token )

The main problem was that `parseGroupExpression` inverts `state.allowArrowFunction`, which leads to some very weird behavior.

This causes the first example above to fail because the inner arrow function isn't allowed. However, if you use two grouping operators, you get a different result!

  (x) => (((y, z) => (x, y, z))) // Error: Line 1: Unexpected token )

Now this is the same bug as the second example above. The inner arrow function gets consumed by `parseGroupExpression`, but since it is an `ArrowFunctionExpression`, the trailing `)` isn't consumed and then fails in `consumeSemicolon`.

The fix for this is to move the arrow function handling from `parseGroupExpression` to `parseExpression`. Now `(x, y) => {}` gets parsed by `parseGroupExpression` as a `SequenceExpression` and then reinterpreted as a CoveredFormalsList in `parseExpression`.

https://code.google.com/p/esprima/issues/detail?id=453
Add range/loc to ObjectPattern and ArrayPattern

https://code.google.com/p/esprima/issues/detail?id=475
Ensure consistent library version across different files.

https://code.google.com/p/esprima/issues/detail?id=470
Use ESLint to lint the code.

https://code.google.com/p/esprima/issues/detail?id=473
Use single-quoted string literals.

https://code.google.com/p/esprima/issues/detail?id=398
ESLint should tolerate assignment to a function.

Until this harmony branch doesn't use the tracker wrapper approach,
we still need to allow assignment to/from a function.

https://code.google.com/p/esprima/issues/detail?id=473
Fix ESLint errors: trailing comma and non-camel case ids.

https://code.google.com/p/esprima/issues/detail?id=473
Allow YieldExpression in an argument of YieldExpression

The current latest draft (Rev 21) allow YieldExpression in an argument
of YieldExpression. e.g. `yield yield v`

https://code.google.com/p/esprima/issues/detail?id=476
Present diffs for mismatched actual and expected JSON.

https://code.google.com/p/esprima/issues/detail?id=478
Expression closure in not supported anymore.

https://code.google.com/p/esprima/issues/detail?id=455
https://code.google.com/p/esprima/issues/detail?id=332
Add more unit tests for arrow functions

https://code.google.com/p/esprima/issues/detail?id=488
Speed up the AST parsing with loc/range tracking.

Summary: https://code.google.com/p/esprima/issues/detail?id=500

filterGroup was very inefficient. It was introduced to fix
https://code.google.com/p/esprima/issues/detail?id=345.
Fixing the same issue in a different (more efficient way) by inlining
the location tracking directly into parseBinaryExpression. The marker
tracking code was taken from the master branch.

The AST parsing with loc/range tracking went from 55s to 30s on a fairly
large (19MB/5000 files) JS codebase.

"npm tests" passes.
Wrapping/unwrapping handlers properly.

Summary: https://code.google.com/p/esprima/issues/detail?id=502

Test Plan: npm tests
Fix ComprehensionBlock and prevent that from happening in the future.

Summary: https://code.google.com/p/esprima/issues/detail?id=505
Added a unit test the ensures that all nodes with 'type' have loc/range
(when it's enabled).

Test Plan: npm test