Get rid of stale jump arrows in disassembly widget.

[beauby]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository
• I made sure to follow the project's coding style
• I've updated the documentation with the relevant information (if needed)

Detailed description

This commit forces the jump arrows to be recomputed upon paintEvent, thus avoiding to draw stale arrows (e.g. after a jump instruction was edited).

Test plan (required)

Cf. #3114

Closing issues

closes #3114

[beauby]

Might also close #2854

[karliss]

If I remember correctly. Not clearing the list was intentional to better support following cases:

• You look at the start of arrow and select the corresponding assembly line. Arrow gets hilighted. You start scrolling down to see the other end. The hilighted line will remain visible as long as it intersects current view even when both ends are invisible.

• Keeping the arrows visible while they are still in screen also has the benefit of minimizing the arrow reordering which makes it easier to visually keep track of what goes where. It's hard to track arrows if their order keeps changing.

A better solution while keeping the two cases above would be to only wipe the arrows after actions that might modify the assembly. Doesn't have to be exact. It's fine if there are some false positives and it removes lines after modification which didn't change the jumps, for example replacing some mov with nop. But scrolling up and down shouldn't remove them, beside the existing code which removes arrows that go outside the screen.

[beauby]

@karliss Thanks for the context. I updated the PR to only clear the arrow starting at that offset when an instruction is edited.

[wargio]

I have tested the patch. it works correctly (at least on linux)