feat: destructuring of structs and messages

[Gusarich]

Issue

Closes #298.

Checklist

• I have updated CHANGELOG.md
• I have documented my contribution in Tact Docs: https://github.com/tact-lang/tact-docs/pull/PR-NUMBER
• I have added tests to demonstrate the contribution is correctly implemented: this usually includes both positive and negative tests, showing the happy path(s) and featuring intentionally broken cases
• I have run all the tests locally and no test failure was reported
• I have run the linter, formatter and spellchecker
• I did not do unrelated and/or undiscussed refactorings

[jeshecdom]

Does this mean that in a statement like:
let { a, b, c, d } = s;
the variable names a, b, c, and d need to match the field names in s?

The following program will produce a compilation error, because the interpreter will be called in the return of testFun2 in order to reduce the call to testFun to a value.

struct S {
    a: Int;
    b: Int;
    c: Int;
}

fun testFun(): Int {
    let s = S{ a: 1, b: 2, c: 3 };
    let { a1, b1, c1, d1 } = s;    // Variable names do not match field names in s
    return a1 + b1 + c1 + d1;
}

// If you remove testFun2, no compilation error occurs because testFun 
// will never be given to the interpreter unless some expression calls testFun
// somewhere in the program.

fun testFun2(): Int {
   return testFun();
}

I think type StructValue needs to be changed so that it not only stores the field names, but also the position number of each field in the struct. So that instead of doing this:
const v = val[idText(name)];
we could do something like this:
const v = val.get(i); // The i-th field in the struct

[anton-trunov]

See my comment for the grammar.ohm file

[anton-trunov]

We need to use an order-independent approach for struct fields, like this:

struct S {
  field1: Int;
  field2: Int;
}

let S { field1: a, field2: b } = struct;
// `a` and `b` are now bound to the `field1` and `field2` components respectively

and also using struct field punning should be allowed too:

let S { field1, field2 } = struct;
// `field1` and `field2` are bound to the respective struct fields

Notice that in the second example the order of fields is not relevant.

This prevents issues with reordering of struct fields in the struct definitions. The currently implemented design would provoke subtle bugs if the user changes the order of fields like so:

struct S {
  field2: Int;
  field1: Int;
}

Since the fields have the same type the refactoring which fails to change the order in the destructuring let-statements isn't going to be frowned upon by the typechecker.