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
Allow some nested inlinings for inlineable classes.

When calling a method on an inlined class instance, the method
is not only identified by its owner and name, but also by the
allocation site of the receiver. This allows some more inlinings
of statically nested uses of inlineable classes.
Optimize Closures directly, rather than AnonFunctions.

AnonFunctions are now simply regular inlineable classes.
Closures are directly optimized as TentativeClosureReplacements,
even when they are not the parameter of a new AnonFunction.

This simplifies the optimizer, notably because it does not need
to know about tricky @specialized apply methods.

It also makes it more powerful: js.Functions can be closure-eliminated
just as well as scala.Functions. Even for scala.Functions, it can
do a better job if the function is applied more than once: the
AnonFunction can still be inlined away, leaving only a JavaScript
function with monomorphic dispatch, which the JS VM should be able
to deal with.
Merge pull request #1176 from sjrd/opt-closures-directly

Optimize Closures directly, rather than AnonFunctions.
Get rid of the box/unbox helpers for Chars.

Basically, java.lang.Character becomes a completely regular
class, that the IR and the tools do not handle in any special
way.
Replace unbox helpers by a dedicated IR node.
Get rid of the systemArraycopy helper by making it an intrinsic.

Intrinsics are a bit like primitives, except that they are special
for the *optimizer*, not for the compiler. This allows to defer
their optimization to link time, if a correct (but non-optimal)
implementation can be written in Scala.js.

This is the case for System.arraycopy, which is the first
primitive to be turned into an intrinsic.

We call these things intrinsics because they are very similar
to JVM intrinsics: methods with a correct implementation in either
pure Java or through JNI, but that the optimizing compilers know
how to handle better.
Improve the implementation of Long.to{Binary,Hex,Octal}String.

It does not use Formatter anymore, and does not require to drop
the leading 0's after the fact.
Turn methods of the j.l.Long companion object into intrinsics.

This allows to get rid of the hack that j.l.Long needed to know
about RuntimeLongs, and in general that Longs are implemented
with this class.
Turn conversions to/from TypedArrays into intrinsics.
Turn System.identityHashCode into an intrinsic.
Get rid of the checkNonNull helper, replace it by codegen.

There was only one place in the compiler where this helper was
used, and it's a rare case. So I simply replaced it by codegen
that does the same thing.
Fix unit test for DataInputStream.readLong().

It's not good to give Longs to Jasmine for comparisons, because
they are converted to Doubles.