Add support for "endless" rule

[eric1234]

This is similar to Ruby's "endless" method. The goal is to allow simple rules to be more compact (similar also to JavaScript's bracket-less arrow functions).

Being more compact (while still readable) allows more code to be seen at once and reduces keyword noise (lots of ends) and excess white space. These two things make it easier to scan and grok the grammar.

I've tested this in a project I am using Treetop for. It reduced the LOC for the Treetop files by 1/4 since a significant number of the rules were simple and could be expressed on a single line. This significantly reduced the scrolling to read the grammar.

This closes #54. See that issue for examples.

[cjheath]

This was still problematic. The semantic predicate you added to ensure that the parsing_rule was all on one line actually looked at the text "rule", the first token, not the last one, which is the parsing rule.

It was a little ugly and I improved that. This change has been pushed to master. Please peruse it there before I publish the gem.

[eric1234]

Just pointed my Gemfile to your branch and run my build process which uses these "endless" rules and it worked great!

---

Great catch on the v.first vs v.last. I guess I should have added a test that purposely failed the parse. Something like:

rule = ('should'
    'fail')

Let me know if you want me to push up that test or if it's good enough for now.

---

I thought about aliasing the [ \t] but couldn't think of a good name since white was already taken (and more expansive) and anything else seemed overly verbose. nbwhite is prefect. Thanks for the cleanup!

[cjheath]

Excellent. I also realised I should have added a test. It still has value, I think. I didn't think of using parentheses, I was thinking of following a broken definition by another rule instead of end. Your way is better.