Ensure that "s" steps through wrappers

[timholy]

My sense is that "s" should step through wrappers but "si" should not. This adds such functionality and tests it.

One thing worth pointing out is that there is a certain amount of "junk" that gets lowered into the caller: using the examples in the new tests,

 julia> Base.uncompressed_ast(first(methods(callopkw2)))
CodeInfo(
1 ─ %1 = (Main.opkw)(0, -1)
└──      return %1
)

but

julia> Base.uncompressed_ast(first(methods(callopkw5)))
CodeInfo(
1 ─ %1 = (:c, :d)
│   %2 = (Core.apply_type)(Core.NamedTuple, %1)
│   %3 = (Core.tuple)(-2, -3)
│   %4 = (%2)(%3)
│   %5 = (Core.kwfunc)(Main.opkw)
│   %6 = (%5)(%4, Main.opkw, 0)
└──      return %6
)

Note that we're in the caller of a kwarg function, not the kwarg function itself. For "normal" stepping (i.e., non-advanced commands) it would be lovely to be able to automatically skip through this. The nicest way to do this would presumably be based on JuliaLang/julia#31162 each frame could also hold line-by-line references to the expression that's being lowered, then you could just go to the last call of the same expression.

[timholy]

Any objections? Might (temporarily) break the stepping logic of Debugger.

[KristofferC]

I think s should step through wrappers as well.

[KristofferC]

Thinking about it a bit more, I now kinda disagree with this.

A frontend who wants to step through wrappers could always previously just insert the maybe_step_through_wrapper!. However, now, there is no way for a frontend to chose not to step through the wrapper?

In addition, previously, I could record that a frame was a wrapper frame by looking if maybe_step_through_wrapper! returned a new frame. And upon returning to that frame I could then use that information to finish the frame. Now, when I return from a frame it is slightly more difficult to know what frames are wrapper frames (but you can probably do it by looking at the length of the stack before and after executing "s")? There is imho some sense to JuliaInterpreter doing the least magic possible but at the same time providing the tools to step over all junk.

[timholy]

However, now, there is no way for a frontend to chose not to step through the wrapper?

You can choose to step via si, right?

Now, when I return from a frame it is slightly more difficult to know what frames are wrapper frames (but you can probably do it by looking at the length of the stack)?

Easier would be newframe.caller === oldframe. Probably also want newframe === oldframe to handle builtins and the like that don't permit stepping in.

[KristofferC]

You can choose to step via si, right?

Yeah but what if I want to step to the next call but not through a wrapper.

I guess my point is that since this is the most low level of the debugger commands, any "magic" we introduce here will propagate to all users of it, and it is harder to clean away the magic, then to just conditionally apply it yourself.