dap: refactor how step in/step out works

Change how breakpoints and stepping works. These now work more how you
would expect another programming language to work. Breakpoints happen
before the step has been invoked rather than after which means you can
inspect the state before the command runs.

This has the advantage of being more intuitive for someone familiar with
other debuggers. The negative is that you can't run to after a certain
step as easily as you could before. Instead, you would run to that stage
and then use next to go to the step directly afterwards.

Step in and out also now have different behaviors. When a step has
multiple inputs, the inputs of non-zero index are considered like
"function calls". The most common cause of this is to use `COPY --from`
or a bind mount. Stepping into these will cause it to jump to the
beginning of the call chain for that branch. Using step out will exit
back to the location where step in was used.

This change also makes it so some steps may be invoked multiple times in
the callgraph if multiple steps depend on them. The reused steps will
still be cached, but you may end up stepping through more lines than the
previous implementation.

Stack traces now represent where these step in and step out areas
happen rather than the previous steps. This can help you know from where
a certain step is being used.

Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>

dap/eval.go

@@ -93,6 +93,10 @@ func replCmd[Flags any, RetVal any](ctx Context, name string, resp *dap.Evaluate
 }
 
 func (t *thread) Exec(ctx Context, args []string) (message string, retErr error) {
+	if t.rCtx == nil {
+		return "", errors.New("no container context for exec")
+	}
+
 	cfg := &build.InvokeConfig{Tty: true}
 	if len(cfg.Entrypoint) == 0 && len(cfg.Cmd) == 0 {
 		cfg.Entrypoint = []string{"/bin/sh"} // launch shell by default