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.
Is this really a good idea? Although probably allowed (I haven't read the spec of the IR), it will change reference equality for longs in the optimization step...