Fix #1163: Remove packager and non-direct full optimizer
Merge pull request #1165 from gzm0/remove-packager

Remove packager
Fix #1154: Add @JSExportDescendentClasses (exports subclass ctors)
Merge pull request #1168 from gzm0/export-all-ctors

Fix #1154: Add @JSExportDescendentClasses (exports subclass ctors)
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.
Remove || and && from the IR, and replace them with Ifs.

lhs || rhs  ->  if (lhs) true else rhs
lhs && rhs  ->  if (lhs) rhs else false
Merge pull request #1166 from sjrd/sanitize-ir

Sanitize IR
Get rid of helpers apply/new JS methods with varargs.

For applying a method with varargs, the codegen directly
emits an appropriate translation.

To instantiate an object with a constructor taking varargs,
instead of a helper, the codegen calls a method of the
scala.scalajs.runtime package object.
Get rid of the helpers {un,}wrapJavaScriptException.

They are replaced by proper Scala.js method in the
scala.scalajs.runtime package object.
js.Dynamic.newInstance returns Object with Dynamic.

Instead of just Dynamic.
Mark js.WrappedDict as inlineable, and override its keys method.
Get rid of the objectClone helper.

By implementing it in Scala.js in the scala.scalajs.runtime
package object.
Merge pull request #1173 from sjrd/get-rid-of-helpers

Get rid of helpers, the easy ones
Fix #1134: asInstanceOf is undefined behavior by default.

`asInstanceOf`s, including unboxing operations, are too expensive.
This commit introduces configurable `Semantics` for the Scala.js
linker. These semantics include the concept of `CheckedBehaviors`,
which describe how we implement some exceptional behaviors, for
now only `asInstanceOf`. These exceptional behaviors have
well-defined semantics on the JVM (throw a particular kind of
exception) even though they should be considered programmer errors.
When compiling to JS, we don't have support from the VM to
eliminate the unnecessary checks, which makes these error cases
too expensive to check.

Each `CheckedBehavior` has 3 possible values:
* `Compliant`: perform the checks and throw the exceptions as
  specified on the JVM.
* `Fatal`: perform the checks, but throw a different kind of
  exception, `UndefinedBehaviorError`, which is a
  `java.lang.Error with s.u.control.ControlThrowable`. It is
  therefore not caught by `NonFatal` clauses.
* `Unchecked`: do not perform the checks.

By default, the `asInstanceOf` checks are in `Fatal` mode. In
`fullOpt`, every behavior in `Fatal` mode is automatically mapped
to the `Unchecked` mode. In this mode, if the program does
something that would have been detected in `Fatal` mode, the whole
program enters undefined behavior, and anything can happen (of
course we're still under the JS VM's control, so the computer
won't explode). If an application needs a particular kind of
behavior to be fully compliant (say because it catches
`ClassCastException`s -- bad!), an sbt setting allows to do so.
Compliant behaviors are kept compliant in `fullOpt`.

ScalaJSKeys.scalaJSSemantics ~= {
  _.transformCheckedBehaviors(_.withAsInstanceOfs(
      scala.scalajs.tools.sem.CheckedBehaviors.Compliant))
}

The idea of the `Fatal` mode is that during development
(including `fastOptStage::test`), portions of code that would
enter undefined behavior are detected with a severe `Error`
that will be reported, and is tractable and debuggable. For
production, all `Fatal` behaviors are turned into `Unchecked`
for maximum performance.

This is similar to how Dart does, for example: a development
mode with more checks, and a production mode where they are
erased for performance.

The same mechanism of `CheckedBehaviors` can be used for other
exceptional behaviors that, so far, we have always treated as
if in `Unchecked` mode:
* `ArithmeticException`, e.g., integer division by 0
* `ArrayIndexOutOfBoundsException` and `StringIndexOutOfBoundsException`
* `ArrayStoreException`

The global concept of `Semantics` can be used to configure
other semantic tweaks, for example, whether `Float`s should be
enforced as 32-bit floats or not.
Merge pull request #1142 from sjrd/asinstanceof-undefined-behavior

Fix #1134: asInstanceOf is undefined behavior by default