JS: fix module aliasing for inline imports (KT-26466 fixed)

Consider an import from an inline function invocation. If it is
being called from another inline function, it should be defined
in a special way (e.g. `$$importsForInline$$.foo`) so that
the compiler knows where to load transitive dependencies from.
What's more, the declaration itself should be inside the inline
function wrapper.

Otherwise it should be defined in a regular way (e.g.
`$module$bar.foo` among other top-level imports).

By default the imports are loaded in the first form, and
transformed into the second one when needed. To check
whether this transformation the following predicate is
used: `inlineFunctionDepth == 0`.

At the moment the mentioned variable is increased upon
visiting an inline function declaration (`defineInlineFunction`),
and upon visiting an unknown (not visited before) inline function invocation.

It seems that instead the variable should be increased when processing
an existing inline function wrapper. At that point a new place to
put import definitions (`statementContextForInline`) is set.

Due to way JS code is generated (lambda's come before their call sites)
this issue seems to have been masked. Primary class constructors are a special
case - they come before any other declaration within. Hence a lambda
invocation inside a constructor leads to incorrect import definition.

js/js.translator/testData/box/inline/inlineChainCrossModule.kt

@@ -0,0 +1,24 @@
+// EXPECTED_REACHABLE_NODES: 1192
+// IGNORE_BACKEND: JS_IR
+
+// MODULE: lib
+// FILE: lib.kt
+
+
+inline fun baz() = pp()
+
+fun pp(): String = "OK"
+
+// MODULE: mid(lib)
+// FILE: mid.kt
+
+fun bar() {
+    foo()
+}
+
+inline fun foo()= baz()
+
+// MODULE: main(mid)
+// FILE: main.kt
+
+fun box() = foo()