Add debug state to papyros editor

[jorg-vr]

This pull request adds a debug state to the papyros editor.

related papyros pr: dodona-edu/papyros#629

When a debug run is started, the editor becomes readonly.
All visualization of generated output, input used and active line is now based on the shown frame instead of the current phase of execution.
While the debug mode is active, the buttons to start a new execution are replaced by an end debug mode button.

[niknetniko]

One minor nitpick: there are some unused imports now in coding_scratchpad.

[bmesuere]

Nice work, this solves a few problems we had before 👍

• I was a little confused by the editor state which was read-only (expected by me while debugging), but this was not shown visually. In fact, you can click the code and a caret even appears which hints that you can edit, but you can't.

• edit: another minor remark: If generating traces is fast (which it often is), the buttons flicker quite a bit between the original, stop and stop debugging. Is there a reason to go to the run state first?

Two smaller remarks not really related to the PR:

• The gutter while debugging is quite big due to the large arrow tail and margin between arrow and line numbers. Maybe we can find a better arrow.
• When clicking on debug, the debugger opens but it is not super clear where you need to click to start the debugging process. We do explain this in the info box at step 0, but even I always have to think for a second. Maybe we can tweak the style of the next step (>) button (make it primary? make it primary only at step 0?)

[jorg-vr]

The gutter while debugging is quite big due to the large arrow tail and margin between arrow and line numbers. Maybe we can find a better arrow.

In debug mode the lint gutter is now replaced by the debug gutter. This way the width doesn't increase. I also used an mdi icon instead of the font arrow so it should now look the same on all devices.

If generating traces is fast (which it often is), the buttons flicker quite a bit between the original, stop and stop debugging. Is there a reason to go to the run state first?

I am not exactly sure this is what you meant, but I changed it so the 'stop' button is shown while the state is 'loading' instead of the run/debug buttons. This mostly makes a difference the first time the debugger is opened (As it is in loading while papyros is fetched).

For fast, but not instant programs there might still be a flickering stop button appearing, before the 'stop debugging' shows up. But this is harder to avoid as I can't predict execution will be that fast.

[jorg-vr]

For fast, but not instant programs there might still be a flickering stop button appearing, before the 'stop debugging' shows up. But this is harder to avoid as I can't predict execution will be that fast.

@bmesuere I have added a 100ms delay on button changes which mostly solves the issue.

Now it is still possible to have a flicker of exactly 100ms of the last open button state. (I added the delay on the general button change function, thus it also happens when changing to 'stop debugger')
But as the buttons are showed at least one 100ms, the flicker feels less odd. Also most often the previous button will either be the 'stop debugger' button (If the debugger wasn't explicitly shut down before opening another case) or the run buttons. (But these are also blue so the flicker is less intrusive)

[bmesuere]

👌
1 last nitpick, but I don't know if it's possible: the cursor is still the "text" cursor over the disabled input area