Add more (infix) operators

[b-studios]

This PR adds a few more infix operators. This is mostly just lexing and parsing so doesn't come with a lot of conceptual cost for the implementation.

A few things are not clear / implemented:

• we should name things consistently (I actually would like to rename infixAdd to InfixPlus, but this will break a lot of things)
• is this slowing down the parser? (for precedence it is now deeply nested)
• is the precedence ok?
• should pipe left and right be by-name? This might open up some cool usages.
• right now the new tokens are added as one batch, we might want to clean them up by sorting them somehow
• I didn't add a === b and a !== b since the tokens === are already used to represent ==, ahhh.

[marvinborner]

what about <<= and >>=?

[dvdvgt]

We decided to make some changes in the Effekt meeting. Thanks!

[marvinborner]

bump

also, what do you think about a := operator? I'd like to use it to overwrite assignments e.g. for references like here

[marvinborner]

If you're already working on this, could you also support infixConcat for lists, arrays, etc.?

[dvdvgt]

I implemented the required changes. I also want to note that currently +=, -=, *=, /= are hardcoded to be transformed to an assignment to local variables. For example

var x = 1
x += 1

is parsed as

var x = 1
x = x + 1

This is of course convenient but precludes us from overloading these operators in the future.

Furthermore, I also added the infix operator r := x and overloaded it for global references Ref[T] to have the semantics of r.set(x). Additionally, l ++ other is now an alias for l.append(other), where both l: List[T] and other: List[T].

I refrained from overloading these new operators for any other types as this already is a pretty "bikeshed-able" PR as it is.

[dvdvgt]

Also, this most definitely will break the communities builds if there any overloads for the renamed infix operators.

[jiribenes]

Although I'm not a fan of many of the extra operators chosen, the implementation itself seems reasonable and extensible in the future, so I'm fine with merging this.

This will likely break a lot of existing Effekt code, but the fix is just simple string replacement, so it's fine.