warn about inlinings that won't happen
code tightening after inlining

- 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.