Have debugger skip anything called from a generated source while stepping

[haltman-at]

PR description

@gnidan noticed a problem whereby a generated source could appear in a stacktrace even though generated sources were turned off. What's up with that?

Well, turns out that in this case, a function in a generated source called another function in that generated source, and due to optimization part of the latter function ended up sourcemapped to a user source! So when you stepped, you would hit that source range, and see that you were now inside a user source called from a generated source. Yikes!

The fix for this is that, if generated sources are turned off, you shouldn't hit such a source range in the first place, as logically it should really be considered to be within a generated source. So I changed it so that, while stepping, the debugger won't stop while there are generated sources anywhere on the callstack (unless you started in a generated source or generated sources are turned on).

Now, I wanted to restrict this new check specifically to generated sources. Normally in the debugger we consider a source to be "internal" if it's either generated, or unmapped, or we just don't know what it is. I was a little worried that this last case could cause some problems, though. And while ideally maybe we'd do the first two but not the third, the thing is that distinguishing the second from the third would require making some changes to the debugger's internals that I didn't want to bother with. (Although, now that I think about it, it actually wouldn't be that difficult, so I can go back and change that if you want.) So this new check only checks specifically for generated sources.

(The existing check regarding the current location -- the top stackframe -- is left in as-is, it's just for the stackframes below that we only check for generated sources.)

Anyway, some changes you'll notice I made:

1. Because we want to distinguish specifically generated sources from other "internal" sources, I added a new isSourceGenerated field to the callstack state in stacktrace.
2. I added a new selector, stacktrace.current.callstack.preupdated. This gives the callstack as it actually currently is, rather than with error information still left on top, much like is used in stacktrace.current.report; that bit of code is now factored out into this new selector.
3. Then there's the changes to the controller described above, sitting on top of these changes to stacktrace.

I think that basically covers everything important.

Testing instructions

I didn't add any automated tets for this PR, I just tested in manually.

This issue was uncovered in Sepolia transaction 0x84f82b79b516aa64f38797f204e09a49e821f7f9353723545dfd600e99b60955. Pressing n twice would land in the messed-up state described above, where pressing s would yield the bizarre callstack.

Now, if you debug this transaction with -x and press n twice, you will skip over that node, and if you press s, you will see a callstack without generated sources.

[gnidan]

Just a minor docs point. Looks good!

[gnidan]

This probably warrants a note about what "preupdated" means