Add direct support for Long in the IR.

This basically delays the translation of Longs to RuntimeLongs from
the compiler to the desugaring. This brings the following benefits:

* It relieves the compiler from the knowledge of RuntimeLong.
* It makes the IR independent of the implementation of Longs (so we
  may change it in the future in a binary-compatible way).
* It allows the optimizer to reason about Longs, in particular to
  constant-fold them.

This prompted several cleanups in the whole Long implementation:
* Incorporate fromString() directly into j.l.Long.parseLong().
* Since done in desugar, "inline by hand" the methods of the
  companion of RuntimeLong. This basically means call directly
  whatever they were forwarding to.
* Hence, there was no method left in this companion, so I could
  merge RuntimeLongImpl back into it, as it used to be.

The whole thing is much cleaner now.
Constant-fold Matches.
Fix {ir,js}.Block.toString().
More constant folding.
Mark Range and Range.Inclusive as inlineable classes.

This removes *all* the overhead if all 3 parameters of the
range are constants. For example,

  for (i <- 0 until 10 by 2) { ... }

If the step is either 1 or -1, and either start or end is
constant (very common case), then almost all the overhead is
removed, except for 3 Long operations. For example:

  for (i <- 0 until n) { ... }
wip