Use the |s| function instead of hardcoded |s0| value

Based on a patch by @fresheneesz:

  https://github.com/dmajda/pegjs/pull/148
Fix buggy position computation

Fixes GH-152.
Fix matching of case-instensitive literals

Code that calculated which part of the input to match against a literal
was wrong in case of case-insensitive literals when generating
speed-optimized parsers. As a result, matching of case-insensitive
literals worked only at the end of the input (where too big length
passed to the |substr| method didn't matter).

Fixes GH-153.
Regenerate src/parser.js

Forgot to do it in 0df8989f7ad95d524b942fafabdc0e37f394969a.

Part of a fix of GH-152.
Fix typo in comment
Merge pull request #188 from vrana/comment

Fix typo in comment
Add initializer example in README.md
Add whitespace to generated action calls

Avoids implicit array to string conversion.
Merge pull request #195 from tonylukasavage/patch-2

Add initializer example in README.md
Merge pull request #196 from vrana/comma

Add whitespace to generated action calls
Regenerate src/parser.js

It wasn't done in beb557d7d33fed5daf691fd18ffe1ed0b9c91a7b.
Fix bytecode built for nested sequences inside actions

In the bytecode generator, the |context.action| property wasn't
correctly reset when generating bytecode for sequence elements. As a
result, when a sequence was wrapped in an action and it contained
another sequence as an element, the generator thought that the inner
sequence was wrapped in an action too.

For example, the following grammar:

  start = ("a" "b") "c" { return "x"; }

was compiled as if it looked like this:

  start = ("a" "b" { return "x"; }) "c" { return "x"; }

This commit fixes the problem by resetting |context.action| correctly.

Fixes GH-168.
Fix |null| handling in the JSON parser

We couldn't return |null| in the |value| rule of the JSON example
parser because that would mean parse failure. So until now, we just
returned |"null"| (a string).

This was obviously stupid, so this commit changes the |value| rule to
return a special object instead that is converted to |null| later.

Based on patches by Patrick Logan (GH-91) and Jakub Vrána (GH-191).
Upgrade jasmine and jasmine-node
Merge pull request #204 from andreineculau/upgrade-jasmine

Upgrade jasmine and jasmine-node
Javascript example: Improve array literal rules

Makes the |ArrayLiteral| and |ElementList| rules more in line with the
ECMAScript grammar.

Based on a patch by @fpirsch:

  https://github.com/dmajda/pegjs/pull/177
JavaScript example: Fix handling of elided elements in array literals

JavaScript allows one to skip (elide) elements in array literals. It
also allows a trailing comma, which doesn't imply an element elision.

For example, an array literal:

  [,,,]

contains three elided elements (one before each comma) and a trailing
comma.

Example JavaScript parser handled elided elements incorrectly and just
threw them away. This commit fixes this behvior and inserts |null| in
the AST for each elided element. This is in line with how SpiderMonkey's
JavaScript parser (the |Reflect.parse| API), Esprima and Acorn behave.

Based on a patch by @fpirsch:

  https://github.com/dmajda/pegjs/pull/177
Fix object literal formatting in generated code
Error handling: Structured expectations

Before this commit, the |expected| property of an exception object
thrown when a generated parser encountered an error contained
expectations as strings. These strings were in a human-readable format
suitable for displaying in the UI but not suitable for machine
processing. For example, expected string literals included quotes and a
string "any character" was used when any character was expected.

This commit makes expectations structured objects. This makes the
machine processing easier, while still allowing to generate a
human-readable representation if needed.

Implements part of #198.

Speed impact
------------
Before:     1180.41 kB/s
After:      1165.31 kB/s
Difference: -1.28%

Size impact
-----------
Before:     863523 b
After:      950817 b
Difference: 10.10%

(Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
Error handling: Use a special value (not |null|) to indicate failure

Using a special value to indicate match failure instead of |null| allows
actions to return |null| as a regular value. This simplifies e.g. the
JSON parser.

Note the special value is internal and intentionally undocumented. This
means that there is currently no official way how to trigger a match
failure from an action. This is a temporary state which will be fixed
soon.

The negative performance impact (see below) is probably caused by
changing lot of comparisons against |null| (which likely check the value
against a fixed constant representing |null| in the interpreter) to
comparisons against the special value (which likely check the value
against another value in the interpreter).

Implements part of #198.

Speed impact
------------
Before:     1146.82 kB/s
After:      1031.25 kB/s
Difference: -10.08%

Size impact
-----------
Before:     950817 b
After:      973269 b
Difference: 2.36%

(Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)