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
Refactor parseObjectProperty to simplify conditional logic.
Remove IllegalYield error and decompose matchYield helper function.

Outside of generator functions, 'yield' is now treated as a normal
identifier, so there is no longer such a thing as an illegal 'yield'
expression, per se. Now, the failure mode is that a 'yield' token might
not be parseable as an identifier (as in 'yield x').
Add tests of async functions and await expressions.
Support async function declarations and expressions.

This support includes arrow function expressions.
Support await expressions.
Remove unreachable code to satisfy code coverage tests.

I tried to write tests that would exercise the removed
matchAsyncFuncExprOrDecl() blocks, but it didn't seem possible. I might be
wrong about that, though.
Fix bug with matchAsync line terminator peeking.

If the next token is 'async' but the current parsing index is separated
from the 'async' token by a line terminator (and possibly other whitespace
or comments), the previous usage of peekLineTerminator() would return
true, improperly causing matchAsync() to return false.

What we want to know is whether the 'async' token is followed by a line
terminator, so we need to fast-forward the lookahead temporarily to just
after the 'async' token, call peekLineTerminator(), and then rewind.