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
Minimize the payload for npm.

Selectively choose which files to include in the module (for npm).
Currently, this is known to break npat=true when doing npm install.

https://code.google.com/p/esprima/issues/detail?id=493
https://code.google.com/p/esprima/issues/detail?id=510
Make npm test work on Windows and ignore node_modules directory

https://code.google.com/p/esprima/issues/detail?id=490
Link to the issue tracker from the package manifest

https://code.google.com/p/esprima/issues/detail?id=491
Manifest package.json must contain author field.

https://code.google.com/p/esprima/issues/detail?id=493
Update Travis CI Node.js versions (0.8, 0.10, 0.11).

https://code.google.com/p/esprima/issues/detail?id=317
[ES6] Pattern params default values

Per latest ES6 draft [1], function parameters that are destructuring patterns
may have default values. This diff allows parsing `AssignmentExpression`
that follows the pattern and `=`.

See tests attached for details.

[1] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions

```
FormalParameter : BindingElement

BindingElement : BindingPattern Initializer[opt]
```

https://code.google.com/p/esprima/issues/detail?id=555
[ES6] Computed properties

Per ES6 spec [1], Object Initializers may have computed properties.

Grammar:

```
ComputedPropertyName[Yield] :
  [ AssignmentExpression[In, ?Yield] ]
```

Examples:

```
var x = 'y';
var foo = {[x]: 10};
console.log(foo); // {y: 10}
```

More complex `AssignmentExpression`:

```
var y = 'y';
({['x' + y]}).xy; // 10
```

Methods and accessors:

```
var foo = {
  [dynamicMethodName]: function() {},
  [conciseMethod]() {},
  *[generatorName]() {},
  get [foo]() {},
  set [foo](v) {}
};
```

In destructuring assignment:

```
var x = 'y';
var {[x]: y} = {y: 10};
console.log(y); // 10
```

Issue #480: https://code.google.com/p/esprima/issues/detail?id=480

[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-initializer
When consumeSemicolon fails to find a semicolon, don't consume anything.

When an ExpressionStatement is not terminated by a semicolon, the
consumeSemicolon function terminates the range/loc of the node at the
beginning of the next node, including any whitespace or comments trailing
after the ExpressionStatement node. Instead, it should revert back to the
end of the previous node.

If you look carefully at the test changes included in this commit (all of
which I made by hand), I think you'll agree they make a lot of sense. The
only ones I'm not sure about are the end-of-Program positions: for
instance, the Program location for '\n42\n\n' now only includes the 42,
and not any of the whitespace. This was already true for the starting
position, but now it is also true for the ending position.

This inclusion of trailing comments/whitespace by consumeSemicolon has
been a very long-standing issue that I dealt with in
https://github.com/benjamn/recast using the
[LocationFixer](https://github.com/benjamn/recast/blob/6feb25024c6883bcfa027b95d3b5fa476ac179e9/lib/parser.js#L72-L101)
class (first introduced in September 2012), but I want to stop using that
class for performance reasons, and I've come to realize I can't correctly
fix all cases anyway (I can rewind over whitespace, but not so easily over
comments, without implementing something like unskipComment), so I believe
this logic is better implemented in esprima.js.