Either disable or properly support `|` in operators

[pchiusano]

(|) a b = 23

> 1 | 2

Yields

  /Users/pchiusano/unison/scratch.u:3:5:
  unexpected |
      3 | > 1 | 2

This works okay:

(+|+) a b = 23

> 1 +|+ 2

This does not:

(|||) a b = 23

> 1 ||| 2

  /Users/pchiusano/unison/scratch.u:1:1:
  unexpected (
  expecting ability, type, or use
      1 | (|||) a b = 23

I'm inclined to just disable it as an operator character for now.

[sellout]

Unison now allows ||| as an operator, but | is reserved for sum types.

| and || are currently identified as keywords in the lexer, which results in error messages like

  I got confused here:   
      1 | (|) a b = 23
    
  I was surprised to find a ( here.
  I was expecting one of these instead:
  
  * ability
  * …

whereas removing their keyword status results in a much better error later in the pipeline (but introduces lots of failures in good code).

  The identifier `|` is reserved by Unison and can't be used as an operator: 
  
      1 | (|) a b = 23

Some questions:

• Why is || hardcoded into the parser? Was it to avoid this exact issue back in the day? Should/could it become a function instead? (I noticed this when reviewing #5273)
• Could | (and perhaps others) be identified as keywords later, allowing contextual use of them as operators? (this also shows up in #5273, as | is given a precedence there, but can’t be used as an operator)

I have a transcript that shows the current (and I think correct-at-the-moment) behavior, but I think there are still a few ways to improve the situation.