Add parsing for function definition

[wavid-b]

Fixes #57

[ahuoguo]

Should we parse functions that have no specified return type? Currently it will result with an error

    add_vars(i32 count) {
        count++;
    }
    BEGIN { }

results in

error[ParsingError]: expected and, or, eq, ne, ge, gt, le, lt, add, subtract, multiply, divide, or modulo
 --> :2:18
  | 
2 |     add_vars(i32 count) {
  |                  ^--- expected and, or, eq, ne, ge, gt, le, lt, add, subtract, multiply, divide, or modulo
  | 

[ahuoguo]

Bug: seems like we cannot parse function calls as statements in function defs

    add_vars2(i32 a, i32 b) -> i32{
        strcmp((a, b), "record"); // TODO fail in type checking
    }

results in a parsing error:

running 1 test
error[ParsingError]: expected statement
 --> :8:9
  | 
8 |         strcmp((a, b), "record"); // TODO fail in type checking
  |         ^--- expected statement
  | 
test parser::tests::test_fn_def_complex ... FAILED

But

    add_vars2(i32 a, i32 b) -> i32{
        a = strcmp((a, b), "record"); // TODO fail in type checking
    }

successfully parses

[wavid-b]

Just found new error unit testing block_from_rule --> drafting request until fixed

[wavid-b]

Known error in rule_from_block not populating AST properly --> to be fixed in the statements_rework branch