Allow | as a separator for list/table literals

Related problem

For the longest time, I considered the [[ column0 column1 ]; [ foo bar ] [ baz car ] [ far fit ]] syntax to be unintuitive and unreadable, and I stuck to the "list of record literals" syntax. Until I realized that this literal syntax is meant to be readable with line-breaks and alignment of the columns:

[[ column0 column1 ];
 [    foo    bar   ]
 [    baz    car   ]
 [    far    fit   ]]

Then @132ikl discovered a really cool bug where the pipe symbol is (for some reason I haven't discovered) accepted by the parser as a list literal delimiter. That makes table literals even more readable IMHO:

[[ column0 | column1 ];
 [    foo  |   bar   ]
 [    baz  |   car   ]
 [    far  |   fit   ]]

This is definitely a bug, since AFAICT the parser doesn't include the pipe symbol as an accepted delimiter for list literals.

So I think we have two options:

1. Fix it by creating a parse error when the pipe symbol is used outside an expression in a list literal

or ...

Describe the solution you'd like

2. Fix it by accepting the the pipe symbol as a delimiter between expressions in a list literal and turning it into an official feature

I know the initial reaction will be that the pipe symbol already has meaning, but so do plenty of other symbols, and I don't think this is ambiguous in the least (but need folks with parser expertise to weigh in, of course).

The good (and odd) news is that it already works today, and seems to work well. For example:

[ ("give" | str length) | ("purple" | str length) ]
# => ╭───┬───╮
# => │ 0 │ 4 │
# => │ 1 │ 6 │
# => ╰───┴───╯

All tests cases already work today where | is used inside expressions inside a list/table literal.

And I may be parser-naive, but the fix looks pretty simple - Just adding the character to parse_list_expression() and parse_list_pattern() and .... (one other place I apparently didn't catch yet, so that a | at the end of a list is ignored like the other separators).

Is this doable, or is it going to cause an issue somewhere else?

Describe alternatives you've considered

No response

Additional context and details

No response

Start by inspecting the parser's parse_list_expression() and parse_list_pattern() functions, then locate the additional separator-handling path mentioned in the issue. Add coverage for pipes between list or table elements, pipes inside expressions, and a trailing pipe. Done means the intended syntax is consistently parsed without breaking existing pipe expressions.