Get rid of anyEqEq and anyRefEqEq and optimize them (a bit).

First, this is closer to what the JVM backend does. Second, it
allows the optimizer to optimize at least the anyRefEqEq case,
if the equals() method can be inlined.

The Object.equals() method is marked @inline so that the test
  x == y
transformed by the compiler into
  if (x eq null) y eq null else x.equals(y)
will become, once inlined:
  if (x eq null) y eq null else x eq y
The latter shape is treated by foldIf case to be reduced to
  x eq y
which completely removes the overhead of the universal equality.
This happens a lot for pattern matchings with case objects, as
well as explicit x == y where x is in fact a type with reference
equality (such as jl.Class).

Optimizing anyEqEq is still pending.
Fix #1132: RuntimeLong.intValue() not preserved by numberIntValue(x: jl.Long).
Optimize BoxesRunTime with the numeric semantics in mind.
Better implementations of unbox helpers.

Use primitive operators that convey more meaning to the VM
as the expected result type.
More constant folding.