Modify semantics to support auto-inserted parens

[rbuckton]

Fixes #81

[littledan]

Thanks for this patch! Will review soon (sorry for my delay).

[littledan]

Seems like, in all cases, the receiver when the decorator is applied to the descriptor is undefined (before and after the patch). Also seems like we are inserting the parens in the parenthized expression case. Everyone good with these decisions? If so, LGTM

[Jessidhia]

It would be nice if the syntax definition could be refactored to be closer to new.

The way I understand this approach is not that it "adds parens for you", but that what's in the parens is just the optional contents of the argument list. @foo and @foo() are identical in the same way that new Foo and new Foo() are.

The way it's phrased in the grammar still sounds like @foo() is a call and @foo isn't; but neither are calls; it's just declaring a function reference and the arguments it should be called with. @(foo()) is a call.

[littledan]

@Kovensky I don't quite follow. With this patch, @foo and @foo() have the same semantics. Are you saying this isn't the right call?

[Jessidhia]

Oh, no, I think this is the right semantics; it's just that, possibly because of the grammar production names, it feels like a monkey patch to the spec.

The suggestion is just to refactor the grammar productions so the parens are seen as an optional argument list instead of a "call-like" expression.

[littledan]

Unfortunately, we can't just use the new grammar directly because it permits square bracket property access, which is syntactically ambiguous with computed property names.