This is, unfortunately, a largeish PR. I think it's not worth reviewing line-by-line in detail, but suggest instead looking at whether the tests are sufficient and doing a quick style review on the rest. (If it's wrong enough to break styling of current features, we'll find that out quickly before we deploy, and if the styling of labeled tuples isn't perfect we can just improve it later).

A few things that make it tricky (but, which, again, I suggest not actually reviewing the implementation of in detail):

• parser-standard is in a very bad state right now. As discussed offline, it's using a version of jane syntax that can't easily be upgraded, so I had to rewrite parts of the labeled tuples jane syntax modules to be compatible.
• Further, the parser-standard parser itself is out of date (and can't be fully updated now), and copying in the labeled tuples parsing from the flambda-backend parser resulted in new parser conflicts (this is why there are changes to make the parsing of local_ in function types to be a little more like the current upstream version - this fixed the conflicts).
• The new terms, patterns and (especially) types have complicated precedence/parenthesization rules due to similarity with existing syntax (e.g., the parameter of (x:int * bool) -> unit needs parens but the parameter of int * x:bool -> unit doesn't).
• Care must be taken with comments and attributes around puns. Following the formatting of labeled arguments, let _ = ~x:x, ~y:y in ... is rewritten as a pun let _ = ~x, ~y in .... These two actually parse the same, so we must do this. But we can't rewrite let _ = ~x:(x [@attr]), ~y in ... because there'd be no place to put the attribute.
• The labels in flambda-backend's parser are just strings, but here they need to be augmented with locations to support accurate comment placement.