warn about inlinings that won't happen
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