JVM Codegen: Step into a function from default arguments

[scaventz]

This is a proposal to fix KT-64731

The main idea is we step into a function, from default arguments assigning(except for default lambda arguments), instead of from header(annotation/modifier/name) of the function. More specifically,for below sample code, the stepping would be:

// TARGET_BACKEND: JVM_IR
// WITH_STDLIB

// FILE: test.kt
inline fun g() = ""                           // line 5

@JvmName("jvmName")
inline fun f(
    p0: Int,
    p1: String = "O",                         // line 10
    p2: String = "",                          // line 11
    p3: () -> String = { "K" },               // line 12
    p4: String = g(),                         // line 13
): String = p1 + p2 + p3() + p4               // line 14

fun box(): String = f(0)                      // line 16

// EXPECTATIONS JVM_IR
// test.kt:16 box
// test.kt:10 box
// test.kt:11 box
// test.kt:13 box
// test.kt:5 box
// test.kt:13 box
// test.kt:14 box
// test.kt:12 box
// test.kt:14 box
// test.kt:16 box

This PR done this by below code changes:

1. Creates IrSetValue with proper offsets in defaultArgumentStubGeneratorPhase phase.

2. For BytecodeInliner

   1. before inline phase, in codegen, we mark line number for the IrSetValue.
      For sample code below, it means linenumber 2 is marked for simpleArg: String = "" and lineumber 3 is marked for stringMaker: () -> String = { "OK" } when we call function foo$default with default arguments.

      inline fun foo(
          simpleArg: String = "",
          stringMaker: () -> String = { "OK" }
      ): String {
          return stringMaker()+simpleArg
      }

   2. In bytecode inline phase, since the default lambda is inlined at call site, there is no astore instruction for the lambda instance any more, we slightly change the logic of extractDefaultLambdasInfo to adapt current design. But what need to be noticed is that we don't mark linenumber for stringMaker: () -> String = { "OK" } in caller, not before or after this pull request, not in BytecodeInliner or IrInliner.

3. For IrInliner

   1. Do same thing as 2.1 described.
   2. In inline phase, we don't mark linenumber for callee in codegen, so the below code is removed from visitInlinedFunctionBlock

      if (inlineCall.usesDefaultArguments()) {
          // $default function has first LN pointing to original callee
          callee?.markLineNumber(startOffset = true)
          mv.nop()
      }