Fix remaining "failing" tests

[lam2mo]

As of #49, there are still five known-failing tests:

• add.lj
• counterexample.lj
• list_remove.lj
• primitive-numbers.lj
• z.lj

These tests eventually need to be thoroughly documented and/or fixed.

[hinescd]

After examination, here's what it looks like to me is causing problems:
add.lj: For equality checks between an int and a double, type inference is not unifying the int to a double
counterexample.lj: Not instantiating functions properly when objects are involved as parameters
list_remove.lj: Java's ArrayList has a method for remove that can take either an index or an element to be removed. It looks like LJ assumes the call is to the method that takes the actual element, so giving it an index instead breaks it. An interesting note is that for Integer lists, the method for removing the given element rather than the element at the given index will always be selected since LJ represents all ints as Integers in the java code.
primative-numbers.lj: Two problems here. One is the same equality problem as add.lj, and the other is a floating point issue that cannot be avoided.
z.lj: The compiler doesn't like having a function called with an argument of a variable whose name is the same as its parameter, but I'm not sure exactly why yet. Interestingly, adding 0 to the argument makes it work again.

[hinescd]

Amendment to list_remove:

On closer inspection I see that LJList has a removeAt method that removes an element at an index. There's a discrepancy between the compiler and the java source for LJList though. The compiler expects removeAt to return something, but the implementation doesn't return anything. Changing

b = a.remove(0)

to

b = a.get(0)
b.removeAt(0)

makes the program run as intended. This problem is also a static analysis problem, since static analysis should catch that a.remove would expect a String for the parameter instead of an Integer.

[lam2mo]

Fixed by 31556a8.