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
Replace wrapTrackingFunction() with inline location tracking.

Summary: Apparently node is not very good at executing these wrapped
functions. Bringing the code closer to the master implementation, but
using local vars instead of the marker stack (markStart/markEnd/markEndIf).

The idea is that all parseXXX functions should return nodes with
range/loc properties set when the tracking is on (master doesn't always
follows it though). I also think this implementation is easier to
maintain and less error-prone than the wrapping one.

I profiled it on a fairly large codebase (5k files/19MB of JS):

Tracking off: master = 3.3s, harmony = 3.2s, my patch = 3.3s (harmony is slightly faster)
Tracking on: master = 5.9s, harmony = 7.8s, my patch = 5.5s (makes it slightly faster than master vs 30% slower)

Test Plan: npm test
Remove NoYieldInGenerator warning message.

It's fine for a generator function to contain no `yield` expressions, just
as it's fine for control flow to dynamically avoid any `yield` expressions
that do appear in the generator function. Permitting no-`yield` generator
functions is one of the stated reasons for the `function*` syntax.

https://code.google.com/p/esprima/issues/detail?id=485
Treat yield as a contextual keyword.

This means, in particular, that `yield` is a perfectly valid identifier
outside the bodies of generator functions, and that it is always treated
as an operator inside the bodies of generator functions.

When we encounter an expression like `yield x` outside a generator
function, parsing fails with an "Unexpected identifier" error pointing to
the `x`, as you would expect with `whatever x`.

https://code.google.com/p/esprima/issues/detail?id=467
UnaryExpression should have prefix: true

https://code.google.com/p/esprima/issues/detail?id=418
Remove unused ClassHeritage enum.

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