Fix two labeled tuple bugs.

[ccasin]

Bug one

(), ~x:(fun y -> y) was being misformatted as (), ~x:fun y -> y, which doesn't parse. I thought this was avoided by the precedence changes in the original labeled tuples PR, but I was wrong.

Now that I've added similar logic and tests to labeled tuple patterns and expressions to make parenthesization coherent, you might ask whether I should pre-emptively do it for types. I believe this isn't needed because labeled tuple type elements use the same non-terminal as normal tuple type elements (atomic_type, see here). On the other hand, when parsing patterns and expressions, a different parser is used for the labeled and unlabeled cases (pattern vs simple_pattern, and expr vs simple_expr).

Bug two

unit -> local_ (x:int * y:bool) was being misformatted as unit -> local_ x:int * y:bool, which doesn't parse.

The parens are needed only if the return is local_ and the tuple's first element is labeled. This is a limitation in the parser. The way ocamlformat handles local_ makes the location of the fix awkward, but ultimately fairly understandable. Hopefully one day we'll rework the local_ printing.

[riaqn]

LGTM - feel free to merge once git signature is fixed.

[riaqn]

For future reference (after discussion with @ccasin )
Labelled tuple types (whose first field is labelled) always need parens on the LHS of arrow types, regardless of local_. This is done in parenze_typ in Ast.ml.
That's also where we should check parens for the RHS of arrow types. But because the RHS depends on local_, which has been stripped away before parenze_typ, we check it elsewhere as done in this PR.

@ccasin thinks we should move local syntax to jane_syntax for maintainability. I want to note that the new mode encoding
ocaml-flambda/flambda-backend#2231
won't help, as it retains the spirit of the old encoding and only uses part of jane_syntax.