Support for message cascades

[Hirevo]

This PR adds support for Smalltalk's syntax for message cascades.

This syntax allows to send multiple sequences of messages to the same object without resorting to a temporary intermediate field.

Message cascades are not part of the base SOM language and are not implemented by any other SOM interpreters (as far as I know), but it is a fun syntax that is added here as an extension.

Here is an example of it, running in the som-rs shell:

(0) SOM Shell | Vector new append: #foo; size println; append: 'bar'; size println; append: #(4 5 6); size println; value
1
2
3
returned: instance of Vector class (Instance(Instance { name: "Vector", locals: ["last", "storage", "first"] }))
(1) SOM Shell | it asArray
returned: #(#foo bar #(4 5 6)) (Array([Symbol(Interned(1)), String("bar"), Array([Integer(4), Integer(5), Integer(6)])]))

Here is another example, showing that binary messages can also be used in a cascade:

(0) SOM Shell | 1; , 2
returned: instance of Vector class (Instance(Instance { name: "Vector", locals: ["first", "last", "storage"] }))
(1) SOM Shell | it size
returned: 2 (Integer(2))
(2) SOM Shell | 1; + 2
returned: 3 (Integer(3))

[smarr]

For the interest of comparability to other implementations, I would suggest to keep it on a branch. I know, these things are fun, though, they may have undesirable consequences down the road.

So, take this as a word of caution, not as a suggestion to necessarily abandon cascades.

[Hirevo]

For the interest of comparability to other implementations, I would suggest to keep it on a branch. I know, these things are fun, though, they may have undesirable consequences down the road.

Yes, I would agree with this.
I just came across this syntax and wondered what would it take to add support for it, I don't personally have any use case for it in SOM.

Also, the implementation done right now is not ideal anyway (like the message sending logic that is duplicated between cascades and regular message sends).
So, I think this PR will likely stay as a draft and not be merged, basically standing to say "if cascades were to be implemented, here is how one could do it".

EDIT: there is now the C-extension label to categorize PRs that are extensions and likely not to be included anytime soon.

[smarr]

Ok :)
Just for reference, a SOM offspring has cascades, the implementation seems a little different: charig/TruffleMATE@cb28ee4