Fix param parser constructor scanning

[jeffijoe]

When parsing an identifier, the parser will treat this.constructor as a single identifier, which means it won't match the constructor token we are looking for when scanning for a constructor. However, when using this?.constructor, 2 identifier tokens would be yielded: this and constructor, which made the parser wrongfully assume it found the constructor. To fix this, the IDENT_PART_EXPR now includes ? as a valid identifier part in order to reduce the amount of false-positive constructor tokens.

However, as I was looking into this, I realized that if you do

const constructor = this?.constructor
return constructor.call(this)

Since constructor is still a valid identifier despite being a reserved keyword, JS allows this, which would similarly make the parser think it found the constructor.

To fix this, the parser will now check if the constructor token is followed by a ( token to consider it a valid constructor. The only false-positive that will get past these checks is

const constructor = something
return constructor(arg)

But I don't think that's a case that's common enough to worry about. Fixing that would require a more complex parser, which will affect performance.

Closes #390

[coveralls]

coverage: 100.0%. remained the same
when pulling 78da08d on fix/param-parser
into c10246c on master.

[coveralls]

coverage: 100.0%. remained the same
when pulling 148225a on fix/param-parser
into c10246c on master.