fix conflicts with list

[pancerZH]

@jpolitz Hi professor, I have located the conflicts and bugs, however, I found one conflict in our design with list team:
In list team, the elements in the list should be the same, or at least assignable to the 1st element, which means:

a = [1, False]

is invalid.
However, in our design, we did have made the destructure assignment possible:

a, b = 1, False

And since the RHS exprs now have been converted to the same AST node {tag: "construct-list", items: []}, the conflict appears.
Now there is only one test case in list tests failed. I am wondering whether the list team could make their limition a little more flexible by removing the limitation of enforcing the same type elements in list?

1) tc for lists
       construct list with different types:
     AssertionError: expected [Function] to throw an error

There is also one way to make we two teams' designs compatible: For [1, 2], we could make it {tag: "construct-list", items: [1, 2]}, and 1, False to {tag: "array-expr", items: [1, False]}. This would solve the conflict perfectly.

[AlexfzL]

There is also one way to make we two teams' designs compatible: For [1, 2], we could make it {tag: "construct-list", items: [1, 2]}, and 1, False to {tag: "array-expr", items: [1, False]}. This would solve the conflict perfectly.

Hello, list group here. To enforce all list members to be of the same type is one of our main design choices, so we do not want to change it at this point. We think it is better if you separate array-expr and construct-list like you mentioned so that you won't fail the typecheck test.

[pancerZH]

@jpolitz Hi professor, I have figured a solution to all the conflicts. Now it should work fine and be ready to merge.