Get rid of redundant operators in the IR.

-x     ->  0 - x     (Int, Long, Double)
~x     ->  -1 ^ x    (Int, Long)
x ^ y  ->  x !== y   (Boolean)

This simplifies the optimizer quite a bit, because less cases
have to be taken into account, the old cases for unary operators
falling into the generalized cases of the binary operators.

Some optimizations applicable to unary operators were not already
supported by the translation, in which case I added them. In the
process, I reproduced similar optimizations on other operators.
For example, to replace the old `~(~x)` becomes `x`, I added the
case `(x ^ (y ^ z))` with literal `x` and `y` folds into
`((x ^ y) ^ z)`, where (x ^ y) is a single literal. This prompted
to implement the equivalent optimization for & and | too.
Turn ClassOf(cls) into a Literal.

Most of the changes are just about moving the `case ClassOf(_)`
to its new rightful place, near the other Literals. The other
changes are removal of the ClassOf case altogether, where the
generic Literal case already does the right thing.
Remove DynType, and replace it by AnyType everywhere.

The JS operations, which were previously only allowed on
operands of type DynType, are now allowed on any operand.

Casts to DynType are obviously removed.

The rationale for this change is that casts to DynType were
always allowed, meaning that AnyType and DynType could contain
exactly the same set of values. The distinction was introduced
at some point to verify that we only used JS operations on
values explicitly asInstanceOf'ed to raw JS types, but now it
only complicated things.
Use less mutable vars and less casts in GenJSExports.
Remove Cast from the IR altogether.

The last few remaining casts generated by the codegen were
converted into proper asInstanceOf's.

There is one remaining hack for RuntimeString, because
j.l.Strings are given to the $this param of RuntimeString
methods, which expect a sjsr.RuntimeString. To address this
without casts, I modified the IR subtyping test so that
j.l.String <: sjsr.RuntimeString. This is a hack, but it is
already less hacky than the cast. Hopefully we'll be able
to get entirely rid of this with proper static methods in the
future.
Fix #1161: Sanitize value equality and other comparisons.

Previously, === and !== were used both for reference equality
and value equality of numbers and booleans, *except* for Longs.
This was confusing, and also too tight to the property that
value equality for numbers and booleans is in fact equivalent
to reference equality.

This commit splits === and !== into 3 pairs:
* ===        and !==        for reference equality
* Num_==     and Num_!=     compare Doubles (including Ints)
* Boolean_== and Boolean_!= compare Booleans

Note that Num_== and Num_!= are also used to compare integer
types, since they are proper subtypes of DoubleType. Hence the
name Num_==, which, even though it does *not* apply to Longs,
proved less confusing than Double_==.
Separating Num_== into Int_== and Double_== also proved too much
trouble, effectively complicating the optimizer very much.

To be consistent with Num_== and Num_!=, the inequality
operators (<, <=, > and >=) were renamed as Num_<, Num_<=, Num_>
and Num_>=. Note that these have always been working on Doubles
and their subtypes, i.e., Ints.