fix(parser): prefer the arrow reading for (args): t => body in expres…

[seprov]

…sion position

The lexer injects ES6_FUN when a parenthesized group is followed by => or :, and the multi-parser forks: one parser consumes the token (the arrow-function reading) and one ignores it (e.g. the expression reading). When the return annotation's type is followed by => and the arrow body is itself valid type syntax -- e.g. f((x: int): int => x), where int => x is also an arrow type -- both parsers run to completion, and the winner was whichever came first in the fork list: the expression reading, f((x: int) : (int => x)).

That preference also breaks the printer round-trip: printing hoists a function body's type constraint into return-annotation position ((module M: SIG) => (module M: SUB) prints as
(module M: SIG): (module SUB) => (module M)), and re-parsing that output under the expression preference yields an ill-typed constraint instead of the original function -- refmt could turn a compiling program into a non-compiling one.

Put the forked (arrow) parser first instead. This matches how the same text already parses in let-binding position, where the bare-constraint reading is not grammatical. Constraining an expression against an arrow type remains expressible with a parenthesized type: (e: ((a, b) => t)); the one fixture relying on the bare form (wrapping-re.t, df_locallyAbstractFuncAnnotated: 'figureMeOut) is updated to that spelling and formats back to byte-identical output.

Fixes reasonml#2925