Improve break-loop stack traces

[fingolfin]

This reworks break-loop stack traces so the initial traceback and later Where() output are driven by the same visible traceback state.

The break loop now tracks both the real environment used for local variable lookup and the first visible traceback frame. That makes ordinary errors, kernel-thrown errors, and no-method-found errors behave more consistently: Where() now shows the same top visible frame that was shown on entry, while method-not-found still keeps its helper environment available for ShowArguments, ShowDetails, and ShowMethods.

This also adds CurrentEnv() for inspecting the currently selected break-loop environment and updates the break-loop docs and tests accordingly.

On top of that, visible stack frames are now rendered with numbered prefixes in the style *[1], [2], [3], where the * denotes the active frame. For me, that makes it much easier to use DownEnv/UpEnv correctly, and also increases readability of in longer traces. The manual examples and special REPL transcripts were refreshed to match the new output.

AI disclosure: prepared with help from Codex for implementation, tests, and documentation.

Resolves #4577

The diff contains many concrete examples where you can see how the stack traces changed in concrete examples. I'd be happy to add additional scenarios if I missed any!

[james-d-mitchell]

On top of that, visible stack frames are now rendered with numbered prefixes in the style *[1], [2], [3], where the * denotes the active frame. For me, that makes it much easier to use DownEnv/UpEnv correctly, and also increases readability of in longer traces. The manual examples and special REPL transcripts were refreshed to match the new output.

This looks really nice in the manual entry you've added, I'll try to take a closer look first thing tomorrow.

[fingolfin]

Note how this used to be missing in the stack trace

[fingolfin]

The introduction of tracebackContext (as a replacement for printThisStatement) is key to fixing the inconsistencies (and not realizing this was probably the main reason I failed before)

[fingolfin]

There are a bunch of manual examples involving stacktraces that are not yet updated. I'll do that.

But I also have a bunch of further ideas for improvements I have, but perhaps better to do them in follow-ups.

[ChrisJefferson]

This is much better. There are numerous ways this could be improved but I think this is good for now, and well tested.

[james-d-mitchell]

Works great, just played around for a while, I think we should merge!

One possible improvement for the future would be to make UpEnv and DownEnv call Where so the context is clear:

brk> DownEnv();
 [1] Error( "!\n" ); at *stdin*:3 called from
 [2] test( n + 1 ); at *stdin*:3 called from
*[3] test( n + 1 ); at *stdin*:3 called from
 [4] test( n + 1 ); at *stdin*:3 called from
<function "test">( <arguments> )
 called from read-eval loop at *errin*:5

[fingolfin]

So it turns out that there are more break loop logs in the manual and some source code than I thought -- and they all are outdated, in fact they already are outdated on master, as none were updated when we made changes to the breakloop in past years.

I already have been working on a PR with further tweaks. Untangling that from the break loop log updates (which unfortunately I made after addition tweaks to the stack trace formatting) would be extra work -- so here is my proposal: we merge this now, as-is, if y'all agree.

Then I'll make another PR which updates those logs, and further tweaks the stacktrace printing. If people like it, we can merge it. If people hate it, I can still do the extra work of updating the logs again (I have to manually interact with that as the AI is confused by code it can't actually execute because e.g. it triggers a segfault intentionally)

BTW some of those logs were so ancient that they can't properly be reproduced. I also found some parts that were showing break loop for a bad reason: they used to show working code, which at some point became illegal, but instead of modifying it to show valid outputs, it was instead modified to show the error -- as a result the log did not fix the surrounding text, or was just not reproducible at all. Argh.

[james-d-mitchell]

if y'all agree.

Agreed!