It makes it easier to understand/debug
Also, drop some unused enum values from that cases

* fully refactor run_tests.py, make it extensible for the future
* an ability to write @compilation_should_fail tests
* an ability to launch run_tests.py for a single .fc file
* keep run_tests.js in sync with run_tests.py
* extract legacy_tests names/hashes to a separate file
  shared between legacy_tester.py and legacy_tester.js

Seeing function name in debugger
makes it much easier to delve into FunC sources

* @fif_codegen to match compiled.fif against an expected pattern
* @fif_codegen_avoid to ensure compiled.fif doesn't contain a substring
* both in Python and JS run_tests
* consider tests/codegen_check_demo.fc for examples

…(...args); }`

This will allow to easily implement camelCase wrappers aside stdlib,
even without changing hashes of existing contracts.
Also, stdlib renamings could be easily performed in the same manner,
even with arguments reordered.

@code_hash to match (boc) hash of compiled.fif against expected.
While being much less flexible than @fif_codegen, it nevertheless
gives a guarantee of bytecode stability on compiler modifications.

…anged

In auto-tests, @code_hash controls bytecode stability.
In legacy tests, expected hashes are specified in a separate file.

They work alongside Lisp-style ;; and {--}, without any #pragma.
Conceptually, a new syntax should be disabled by default
and activated using a special compiler option.
But now, we don't have an easy way to provide compiler options
in func-js, blueprint, etc.
Note, that introducing per-file #pragma is a wrong approach here,
since if we want to fire human-readable error on using '//' without pragma,
lexer should nevertheless work differently.
(this could be controlled by a launch option, but see above)

In stdlib, all existing pure functions are asm-implemented.
But since we introduced a `pure` keyword applicable to user-defined functions,
we need to check that they won't have any side effects
(exceptions, globals modification, etc.)

…ation

Note, that I have not added all builtin functions.
I filtered out strange and actually unused in practice,
like "int_at()" and similar, or "run_method0()" and similar.
(Probably, they should be dropped off even from builtins)

Also, I've modified some stdlib.fc legacy tests just to ensure
that a resulting hash doesn't change.

All tests pass: it does not affect hashes (since modifying
variables in a single expression was an error)

It changes all hashes, since the compiler needs to manipulate the stack
in a different way now.

…_Let

Before, #pragma allow-post-modification produced Op::_Let for every
tensor entity (which became non-disabled if modification really happened).
Although they are stripped off by the compiler and don't affect fif output,
they pollute intermediate "AST" representation (ops).
Now, Op::_Let is added only if var modification actually happens
(which is very uncommon for real-wise code)

Before, such code `if (slices_equal() & status == 1)` was parsed
as `if( (slices_equal()&status) == 1 )`.
Note, that this change leads to hash changes of some verified contracts,
but a new priority is more expected from the user experience.

`get` keyword behaves exactly like `method_id` (auto-calc hash),
but it's placed on the left, similar to Tact: `get T name()`.

`method_id(n)` is still valid, considering it can't be invoked by name,
since a client will compute another hash.
It's supposed it will be still used in tests and in low-level code
(not to be called externally, but to be called after replacing c3).

`get(hash)` is invalid, this keyword does not accept anything.

As it turned out, PSTRING() created a buffer of 128K.
If asm_code exceeded this buffer, it was truncated.
I've just dropped PSTRING() from there in favor of std::string.

Example: "flags & 0xFF != 0" is equivalent to "flags & 1",
most likely it's unexpected.
Example: "a << 2 + 1" (equal to "a << 3", probably unexpected).

The only way to suppress this error for the programmer
is to use parenthesis.