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.
It must be this way:
* If the literals on both sides are the result of folding a same initial `Long` through two different paths, we must preserve the result `true`.
* If the literals are different, of course we must preserve the result `false`.
* If the literals are the same, but were not folded through the same path, we *can* use `true` because we are allowed to intern `java.lang.Long`s if we so wish, in an arbitrary way.