Add `call` blocks for calling many functions sequentially

Currently, Dyon's syntax requires you to add a new line for every function call.

Consider the following use case of placing building blocks:

bl bl bl py bl bl mx bl bl my bl sk bl bl mx bl bl py bl bl px bl

In my project, this generates the image:

The problem is that the instructions has to be placed on single lines:

bl()
bl()
bl()
py()
bl()
bl()
mx()
bl()
bl()
my()
bl()
sk()
bl()
bl()
mx()
bl()
bl()
py()
bl()
bl()
px()
bl()

This takes up much more screen space and is annoying because only a few characters are needed per instruction.

I suggest adding a call block, such that I can write:

call { bl bl bl py bl bl mx bl bl my bl sk bl bl mx bl bl py bl bl px bl }

The call block does not accept function calls that return some value or take arguments.
The whole purpose is to specify a list of functions to call sequentially, with least amount of typing as possible and performing as fast as possible (see the section "Optimization" below).

Applications

• Generating geometry in 2D and 3D
• Generating low-level hardware instructions

While it is easy to design a custom DSL (Domain Specific Language) using e.g. Piston-Meta to do this,
it is more convenient to combine such instructions with general Dyon code for flexibility.

Optimization

In addition to being more ergonomic, it is possible to speed up type-checking and runtime performance since it is known that there are no arguments, lifetimes or return values to type check.

Data Extraction

A call block might be given a label such that you can store call instructions inside Dyon code and use extract_calls to get them:

test.dyon:

fn main() {
    call 'name { a b c }
}

To extract to call instructions:
abc := unwrap(extract_calls(file: "test.dyon", label: "name"))

The extract_calls__file_label(file: str, label: str) -> res[[str]] function takes meta-data from Dyon's syntax and looks up the node with call instructions. Other variants of this function can be used with meta-data for storing call instructions inside similar DSLs which have a syntax specified by Piston-Meta.

The idea is that when using call blocks, you also make them accessible by tooling. This is the opposite of normal code, where data gets less accessible because it was turned into code.

Start with the test.dyon example and the described extract_calls__file_label(file, label) entry point, then review how existing function-call statements are represented. Done means supporting labeled and unlabeled call blocks with sequential no-argument calls and exposing their instructions through the proposed extraction API.