Fix #428: Improve matcher for Rhino stacktraces
Merge pull request #429 from gzm0/fix-rhino-matcher

Fix #428: Improve matcher for Rhino stacktraces
Version 0.4.2.
Towards 0.5.0.
Rename scala.scalajs.runtime.Long => RuntimeLong.

This is similar to RuntimeString, and has the strong
advantage not to clash with, well, Long.
Fix #410: x.toByte and x.toShort should ensure the proper range.
Do not box Booleans, Doubles and Longs.

These three primitive types have a perfectly valid and
identifiable JavaScript representation already, respectively
boolean, number and RuntimeLong. Therefore, there is no need
to box them in a java.lang.{Boolean,Double,Long}.

The only thing that we lose semantically by doing this is
that the toString() method of a Double will not add the .0
it used to add when the value happens to be an integer. For
consistency, this behavior has also been removed from Float.
Do not box Ints.

Contrarily to the previous commit, where non-boxed values could
still always be identified in an accurate way, in this commit
we cannot do that anymore.

Since both Ints and Doubles are non-boxed as numbers, and their
values overlap, we cannot always tell whether a value was
initially an Int or a Double. Specifically, all integer numbers
will answer true to isInstanceOf[Int] *and* isInstanceOf[Double].
Hence, all Ints are also Doubles, and some Doubles are also Ints.
Do not box Floats.

Boxed Floats and Doubles are now complete indistinguishable. Any
Float will answer true to .isInstanceOf[Double], and vice versa.

This is fine, because floats and doubles already behave exactly
the same way when they are primitives, since they are both
represented as numbers and all operations on them are the direct
equivalent on number.

Double is slightly privileged compared to Float in the sense that
x.getClass() will return classOf[java.lang.Double] (and not Float)
when x is a non-integer number.
Do not box Bytes and Shorts.

Again, this reduces the ability to distinguish a boxed Int from
a boxed Byte or Short. Here, we use the same range-based approach
as for Int vs Double: a number x will answer true to
x.isInstanceOf[Byte] (resp. Short) if it is an integer in the
range [-128,127] (resp. [-32768,32767]).

However, Integer is still privileged over Byte and Short in the
sense that x.getClass() will always return
classOf[java.lang.Integer] for integer values, regardless of their
range.
Do not box Unit.

The unique instance of scala.runtime.BoxedUnit is now
represented as the JavaScript undefined. This will alter
the result to ().toString() which is now "undefined" instead
of "()".
Use Scala primitive types instead of JS types by default.

With the removal of boxing introduced in the preceding commits,
the runtime representation of all JavaScript primitive types has
a direct corresponding Scala type.

Hence, Scala types such as Int or Double can now be used where
previously a js.Number was required to ensure no boxing would
occur.

Sometimes, the actual JavaScript types are still useful, either
to access their methods, or because they can hold the undefined
value as an additional possible value. But most of the time they
should not be needed.

This commit hides away primitive JavaScript types under
scala.scalajs.prim._, and replaces all occurrences of primitive
JS types by their Scala equivalent (or more precise, such as Int)
where applicable. Only a few places still use the real JS types.
Add type aliases from disappeared js._ types to their Scala types.

This encodes in the type system itself that the default type
to use to represent a JavaScript number (resp. boolean, string, and
undefined) is scala.Double (resp. scala.Boolean, java.lang.String,
and scala.Unit).

It will also allow most codebases to upgrade smoothly to actual
primitive JS types having been hidden away in js.prim._.
WIP Exact semantics of Int. Needs tests.