Fix parse error when static class method comes after proto method

This fails to parse:
`class A { foo() {} static bar() {}}`

I'm not sure exactly why the strict branching check was put in place, but we
don't need to do much more than check if the first token is 'static' when
parsing a method definition -- so this works and fixes the issue.

All tests pass, etc

https://code.google.com/p/esprima/issues/detail?id=430
Implement a LocationMarker object type.

This change gives a noticeable performance improvement on the harmony branch, when either the "loc" or the "range" parsing options are enabled.

Note that test/benchmarks.js does not enable either of these options, and so those benchmarks don't show any improvement with this patch applied.

When I run `node test/runner.js`, I see a consistent 38% decrease in running time (from ~1100ms to ~680ms on my machine).

When I run the same test suite in Chrome 28, the running time drops from ~1700ms to ~1200ms (a 30% decrease).

When I run the test suite in Firefox 21, the running time drops from ~2300ms to ~2000ms (a 13% decrease).

The performance win is attributable to inheriting the end, applyGroup, and apply methods from LocationMarker.prototype instead of redefining them for each instance.

https://code.google.com/p/esprima/issues/detail?id=429
Support ES6 default parameters.

https://code.google.com/p/esprima/issues/detail?id=432
ES6: Do not allow rest parameter to have a default value.

https://code.google.com/p/esprima/issues/detail?id=367
https://code.google.com/p/esprima/issues/detail?id=432
Use the updated module import declaration syntax.

https://code.google.com/p/esprima/issues/detail?id=410
Make sure default parameters are also available in function expressions.

https://code.google.com/p/esprima/issues/detail?id=432
Use the updated module export declaration syntax.

https://code.google.com/p/esprima/issues/detail?id=410
Use the updated module declaration syntax.

https://code.google.com/p/esprima/issues/detail?id=410
Obey automatic semicolon for export default.

https://code.google.com/p/esprima/issues/detail?id=410
Only allow export declaration inside a module body.

https://code.google.com/p/esprima/issues/detail?id=410
Allow top-level export declaration.

This prevents a SyntaxError when using export within a Module, instead
of a Script.

If the consumer needs to detect the wrong use of ExportDeclaration in a
Script, this can be done via a post-processing of the syntax tree.

https://code.google.com/p/esprima/issues/detail?id=410
Disallow nested module declaration.

https://code.google.com/p/esprima/issues/detail?id=410
Add a test case for import within a module.

https://code.google.com/p/esprima/issues/detail?id=410
Named exports can have optional module specifier.

This is basically implementing

  ExportSpecifierSet ::=
    "{" (ExportSpecifier ("," ExportSpecifier)* ","?)? "}"
    ("from" ModuleSpecifier)?

https://code.google.com/p/esprima/issues/detail?id=410
Distinguish between default vs named import specifiers.

https://code.google.com/p/esprima/issues/detail?id=410
Allow ReservedWord to be used as export and import names.

https://code.google.com/p/esprima/issues/detail?id=410
Parsing empty switch contains 'cases' key

SpiderMonkey and the Parser API defined 'cases' to be in the
SwitchStatement production.

https://code.google.com/p/esprima/issues/detail?id=436
Allow 'default' for exported variable declaration.

https://code.google.com/p/esprima/issues/detail?id=410
Allow 'default' for exported function and class.

https://code.google.com/p/esprima/issues/detail?id=410
Support parsing 'export default = <assignment expression>'.

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