Check that all class vars assigned to in constructor

[JSAbrahams]

Relevant issues

Closes #298 .

Summary

Type checker checks that all class variables are assigned to in the constructor.

Should not conflict with class-levle declarations (i.e. MyClass(def x:Int)) as this already conflicts with constructors. This means that the type checker gives an error in such a situation, and we needn't deal with it.

Some other parser stuff:

• Make assign always top-level in constructor
  • Had to move around (and simplify, which is nice) some check logic to deal with the new way ASTs of assigns and property calls are handled. Meaning, property calls are now always embedded within assigns, and not the other way around where you have a chain of property calls and an assign at the very end which doesn't make much sense.
• Remove Node Init and _Self. Could've been separate PR, but it was making the application logic here needlessly complicated so I just removed it in one go.

Added Tests

• Checker allows non-assignment to nullable values.
• Checker does not allow non-assignment to non-nullable value (in constructor).
• Reassign is top level instead of property access in parser

TODO Will add tests for top-level tuples as well. TODO check if this all solves #297 .

Generally speaking, this should be another stepping stone towards fixing #188 .

[codecov[bot]]

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop@a40970e). Click here to learn what that means. The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop     #300   +/-   ##
==========================================
  Coverage           ?   86.37%           
==========================================
  Files              ?      100           
  Lines              ?    10072           
  Branches           ?        0           
==========================================
  Hits               ?     8700           
  Misses             ?     1372           
  Partials           ?        0           

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[JSAbrahams]

Once we properly deconstruct the IdentiCall in the generation stage, I believe that this all should work. We need to properly map between expressions and the associated calls though for this to work.

[JSAbrahams]

when running unassigned_tuple_second_nullable, we have the following constraints on this branche:

Constr: {left}  Int? == `self.z`
Constr: {left}  `self.z` == X.z
Constr: {left}  Int == `self.y`
Constr: {left}  `self.y` == X.y
Constr: {left}  `self` == X
Constr: {left}  `type tuple` == (Int, Int?)
Constr: {left}  (Int, Int?) == `(y@0, z@0)`
Constr: {left}  `self` == X
Constr: {left}  `self@0.y@0` == Int
Constr: {left}  Int == Int
Constr: {left}  `self@0.y@0` == `self@0`.y

And the following on develop:

Constr: {left}  Int? == `self.z`
Constr: {left}  `self.z` == X.z
Constr: {left}  Int == `self.y`
Constr: {left}  `self.y` == X.y
Constr: {left}  `self` == X
Constr: {left}  `type tuple` == (Int, Int?)
Constr: {left}  (Int, Int?) == `(y@0, z@0)`
Constr: {left}  `self` == X
Constr: {left}  `self`.y == Int
Constr: {left}  Int == Int

We appear to be getting a lot of @ because we are incorrectly shadowing variables when we shouldn't be.