squash outer pointer of Late-Closure-Classes

During UnCurry, closureConversionModern() lowers a Function node into
a Block of the form:

    {
      def hoisted(x_1: T_1, ..., x_N: T_n): R = body

       ScalaRunTime.lccMethodDisguiser(
         hoisted(zeroes-for-params-above)
       ).asInstanceOf[AbstractFunctionN[T_1, .., T_N, R]]
    }

The "hoisted" method becomes a bytecode-level instance-method,
unless the class declaring it is an implementation-class derived
from a trait (in which case "hoisted" becomes
a bytecode-level static method).

An instance "hoisted" method usually implies that an outer-pointer
is required by the anon-closure-class (unless the class declaring
the "hoisted method" is a Scala-level static module, in which case
the anon-closure knows how to grab the correct instance via
GETSTATIC MODULE$ thus doing without an outer-pointer)

Oftentimes an instance "hoisted method" actually does not depend
on THIS, or depends only on lifted-methods (thus not part of
the public API) which themselves exhibit such property (not depend
on THIS or depend only on methods that don't actually require THIS).

In class LCCOuterSquasher, method squashOuterForLCC() detects
the largest subset of "hoisted methods" (aka endpoints)
that can be made static, under the constraint that only
lifted-methods can be made static. This constraint amounts
to leaving the public API unchanged.

Once that subset has been determined, all usages of those
"must-be-made-static" methods are found, and rewritten as appropriate.

Finally, each Late-Closure-Class amenable to this transformation
is refactored:
  - its $outer field is removed,
  - its constructor is adapted removing the param for outer-pointer.

Compiler flag -Ylog:jvm informs which anon-closures have
their outer-pointer squashed.
bytecode-repository for method-inlining purposes
bytecode-repository for closure-inlining purposes
making final those methods we want to be inlined
new optimizer: method inlining, closure inlining

The ICode-based inliner has a few problems:

  (a) closure elimination is implemented as repeated method inlinings.
      Upon being forced to stop with that (e.g., recursive method)
      none of the previous inlinings is undone, leaving both
      the closure class and a trail of duplicate code.

  (b) code may be inlined from third-party libraries or the JDK.
      In general methods not marked @inline may be inlined as discussed
      in thread the perils of inlining

  (c) invocation cycles (ie M1() calling M2() calling M1() etc)
      are "broken" only after hitting the maximum method size
      threshold, leaving a trail of duplicate code behind.

Instead, the new optimizer just follows a simple principle:

    only inline @inline-marked methods, and always inline them,
    including under separate-compilation

Thus the new inliner is deterministic, not dependent on heuristics
about method sizes or similar. The only additional requirement
(if you will) is for the method to be dispatched (the one marked
@inline) to be determined via the static type of the receiver.
For example, in a Range.foreach() callsite the type of the receiver
must be Range or subtype (in general, not a super type of another
which overrides the @inline method). After all, inlining is a conscious
decision: making that explicit via the type of the receiver is
 straightforward. As a result, the @noinline annotation doesn't play
a role anymore.

Under -Ylog:jvm , the new optimizer provides detailed logging about
performed inlinings, as well as diagnostics when inlining proves
unfeasible (down to the culprit bytecode instructions).