Verify that debuggers are reset after TDML tests are run

[stevedlawrence]

Current behavior in Daffodil is to automatically disable debugging after a call to runOneTest, which helps to avoid errors where enabling debugging in one test might cause failures in another test.

This updates a test to use the latest TDML API and confirm that this behavior actually happens. Note that the schema that originally found the issue with long-lived debugger state is no longer valid in Daffodil, so it needed some tweaks. This also simplifies the custom debugger to avoid storing strings that are never needed.

DAFFODIL-790

[mbeckerle]

+1

I found a typo in a comment.

[mbeckerle]

Typo numeLines

[tuxji]

+1

I'm not familiar with this approach to debugging Daffodil. Do I understand that the InteractiveDebugger class here does not mean that you interact with a live interactive debugger command line, rather, it lets you supply a callback "listener" class which can trace parts of Daffodil execution and print or accumulate data to help you debug a problem?

[stevedlawrence]

Do I understand that the InteractiveDebugger class here does not mean that you interact with a live interactive debugger command line, rather, it lets you supply a callback "listener" class which can trace parts of Daffodil execution and print or accumulate data to help you debug a problem?

Yep. There's a number of commands that the interactive debugger understands (e.g. "break", "step", "continue", "eval"). The "listener" or "debugger runner" is what provides the commands to run and receives the results to display. The name "interactive" is probably not the best since it really doesn't need to have user interaction at all (e.g the TraceDebuggerRunner just uses a list of predetermined commands). But I think it originally did require user input, but was eventually generalized and the name stuck.