Introduce COMMA! as expression barrier datatype

[hostilefork]

Expression barriers were initially developed as the vertical bar. But over time the inability to use that same tool in PARSE (due to | being taken for alternate rules), as well as the bulk of the bar and its seemingly sematnically "heavy" suggestion...guided the idea of using a new COMMA! type:

>> all [1 + 2, 3 + 4]
== 7

>> all [1 +, 2 3 + 4]
** Script Error: + is missing its value2 argument

>> all [(1 +) 2 3 + 4]  ; error parity
** Script Error: + is missing its value2 argument

This implements the type, with its unusual rendering property of gluing itself to what's on the left...despite being a separate countable element in the array:

>> length of [a, b]
== 3

It also does a quick patch of the feature into PARSE:

>> parse "aaabbb" [some "a", some "b"]
== "aaabbb"

>> parse "aaabbb" [some, "a" some "b"]
** Script Error: expression barrier hit while fulfilling argument

[giuliolunati]

A great improvement toward "natural-language-ness"! I'm totally favorable.

[hostilefork]

This is now merged.

Since I'm liking it, and this seems to have "widespread support" :-) I've gone ahead and changed the codebase away from BAR! to use it.

Read over those changes if you can and see if it gives you any thoughts.

So obviously the COMMA!s main intention is for code, and not data. But there still might be some data-oriented dialects that use it.

One interesting thing is that you can put commas at the beginning of lines. This is an idiom that appears in a lot of languages these days, to make it easier to add and remove lines without touching the line above in version control:

 all [
     , some expression here
     , another expression here
 ]

And of course trailing commas on the last line are legit too:

 all [
     some expression here,
     another expression here,
 ]

I think that likely the decimal format with commas should be killed off.

Keep me posted on any findings.