Fix string/comment parsing and member_expression associativity (#52 and #53)

[mallyskies]

Fixes two parsing bugs affecting Haxe 4.x code:

Issue #53 — Strings swallowing inline comments

The string rule consumed // as part of the string content, causing any string
literal followed by a line comment to produce a malformed AST for the remainder
of the expression. Fixed by anchoring the string rule to stop before //.

Issue #52 — member_expression was right-associative

a.b.c was parsed as a.(b.c) instead of (a.b).c. The prior rule used
repeat1(field('member', $._lhs_expression)), which greedily consumed nested
member expressions into the RHS. Fixed by switching to a left-recursive binary
form with prec.left:

member_expression: ($) =>
  prec.left(1,
    seq(
      field('object', choice('this', $.identifier, $.member_expression, $._literal)),
      choice(token('.'), seq(alias('?', $.operator), '.')),
      field('member', $.identifier),
    ),
  ),

Also added [$.member_expression, $._lhs_expression] to the conflicts array
to resolve the GLR conflict that arises in optional-chaining contexts.

Bonus fixes included in the first commit:

• enum abstract declarations now parse correctly
• struct typedef bodies parse correctly

Verified against ~7,000 Haxe source files with zero parse errors.