Location info

This Pull Request Adds a few things to pegjs, I ran into the following problems when trying to add location info using the existing line and column api especially when trying to calculate the end line and column. This info is needed when trying to select a range in an editor. I found that getting location info severely slowed down the simple json parser and adding end line and column information made the parser nigh unusable for non trivial inputs. 

When I started adding location info, the next logical step was to correlate that with JavaScript errors, one of the toughest problems to track down, when your debugging a grammar. For this I added a lintableJavascript option to the parser this string is a proxy for the finished parser with all the javascript blocks matched up line and column wise with where they were in the source grammar, so if running this string through jshint says there is an error on line 19 column 1 when you go to look for it in the source the offending error will actually be on line 19 column 1. 

For completeness I also added a ast option for output of the parser, this would enable things like creating an outline of grammar that would allow you to jump around to different rules easily. 

1: location info to all AST Nodes this is an object with the following signature

{
   start: { line:1,column:1, offset:0},
   end: {line:1, column:2, offset:1},
   range: [0,1],
   source: " "
}

2. expose the ast as a option for the output of the parser

3. add a fourth option for the output of the parser lintableJavascript, this option produces a string with the javascript blocks in the same line, column (within reason) as the pegjs source for feeding into jshint, esprima etc... it also declares labels and rulenames before each block

4. redo of the way lines are calculated: the current method of calculating lines works very well if your only interested in the start line of an ast, however with longer input and calculating the end line of an ast node the current method does not scale well. I switched it to use the method that esprima uses. This is as new lines are found in the source they are stored in an array indexed by their position and containing the new line count so far. Thus given a position we see if it has a corresponding entry in the array if so the position is the start of a new line so return the item at that index (line count to that point) and column is 0. If there is not an index at the given position we decrement  the position and and increment the column by one and repeat until we find the line number. 

a demo of the possibilities of this is available here https://preview.c9.io/kwesibrunee/snmpstack/PegJs/editor.html though it uses a slightly older version of 8.0 and is still very much a work in progress.  

here is also some screenshots of the editor I am working on. 

![editor](https://cloud.githubusercontent.com/assets/2761593/4927173/314ae8bc-6539-11e4-80ef-937ea44b87c1.png)
![editor2](https://cloud.githubusercontent.com/assets/2761593/4927172/3148f1d8-6539-11e4-8a69-f8336c9312ab.png)


You added parameter to the constructor and why you don't use it?