partial fix issue #21: DisasmViewer reloads on Breakstate

[pvmm]

There seems to be a much simpler solution for issue #21: we reload DisasmViewer code window when we enter break state. A bit of a waste of resources, but the impact is negligible.

[m9710797]

Seems like a good idea.

[sdsnatcher]

I feel obligated to thank you so much for this fix.

• It follows the KISS principle
• It passed my "trial by fire" test for this problem. I'll describe it here:

---

The use case is: to debug two simultaneous sessions of an MSX-DOS game side by side. One session runs the original game, the other runs an enhanced version you've been working. You're trying to compare when one of the two is misbehaving (either an original bug that was fixed, or something that worked and there's a new bug that you introduced).
You don't have the original source code of the game. This is all hacking/reverse engineering.

1. What was being tried:
   a) MSX-DOS executables are all loaded at 0x0100.
   b) Most DOS games load a succession of executables for each part of the game
   c) You place a breakpoint at 0x0100 to check when each of the executable is being started
   d) Going back and forth from the openMSX App that is running the original game and the openMSX App running the patched game

2. What was a nightmare:
   a) The debugger didn't notice that a new MSX-DOS executable was loaded at 0x0100. The code from any of the previous executable was usually shown. The developer stepped for many incorrect instructions puzzled by the misbehavior before realizing that the Z80 instructions being shown were all bogus
   b) The same problem occurred when disconnecting form one openMSX App and connecting to the other

---

This PR finally makes this use case functional.