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.
duplication removed in GenBCode's Worker2.visit()
tracking Late Closure Classes
bytecode-repository for method-inlining purposes
making final methods we want to be inlined

The final status shows up in .check files for presentation tests,
in particular for the more complete output produced since commit
12dd8c02bbb71233f7b8ab9b2cbf8e84cda2080d

Thus those check files are updated in tandem with
the methods made final in this commit.
new optimizer: method 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
      at the scala-internals 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).
new optimizer: closure inlining

Closure inlining results in faster code by specializing
a higher-order method to the particular anonymous closures
given as arguments at a particular callsite
(at the cost of code duplication, namely of the Hi-O method,
no other code gets duplicated).

The "Hi-O" method usually applies the closure inside a loop
(e.g., map and filter fit this description) that's why a hi-O callsite
can be regarded for most practical purposes as a loop-header.
"Regarded as a loop header" because we'd like the JIT compiler
to pick that code section for compilation.
If actually a loop-header, and the instructions for the hi-O method
were inlined, then upon OnStackReplacement the whole method containing
the hi-O invocation would have to be compiled
(which might well not be hot code itself).

To minimize that wasted effort, `inlineClosures()` creates a dedicated
(static, synthetic) method for a given combination of hi-O and
closures to inline (not all closures might be amenable to inlining).
In that method, closure-apply() invocations are inlined,
thus cancelling out:

  - any redundant box-unbox pairs when passing arguments to
    closure-apply(); as well as

  - any unbox-box pair for its return value.

As part of closure inlining, two code tightenings are also performed:

- prune unneeded arguments to a static-HiO method synthesized
  due to closure-inlining

- reuse if possible an already emitted static-HiO method
new optimizer: GC-savvy closures

This commit adds support for singleton closures, and for
closure state minimization. The optimizations in question are
intra-program, thus get applied at level -neo:o2 or higher.

  (1) Some anonymous closures depend only on apply() arguments,
      ie they capture no values. In such cases, code is emitted
      that avoids repeated closure allocations by keeping
      (in a static field added to that effect) a singleton-instance
      that is reused.

  (2) Lack of usages of a Late-Closure-Class (eg as a result of
      dead-code elimination) means the closure can be elided,
      along with its endpoint. This may lead to further tree-shaking
      (via UnusedPrivateDetector).

  (3) Minimization of closure-fields (in particular, outer)
      to those actually used. Field removal requires adapting both
      the closure allocation site, and the Late-Closure-Class itself.
      For example, removing the outer-pointer also requires turning
      the closure's endpoint into a static method.
      Closure allocations remain, but with smaller GC overhead.
no more outer pointer in nsc.backend.jvm.BType
nsc.backend.jvm.BType is a custom value class
Level 1 intra-method optimiz: closure-state minimization
styling dclosure endpoints for LambdaMetaFactory

An aspect relevant for future compatibility with JDK 8.

A LambdaMetaFactory in JDK8 delivers lambdas that assume
the (hoisted) target method to have arguments for all captured values
and for apply-args (in that order).

In contrast, "hoisted target methods" emerge from LambdaLift with
formal-params for captured values appended after those for apply-args.

Moreover, for mixins, the first formal of an endpoint in
an implementation class denotes the self-reference.

This commit makes dclosure-endpoints ready for LambdaMetaFactory.