Implement memory breakpoints (not sure if done)

I saw three methods to do this:

1) Keep a LISTARRAY of the byte values at every breakpoint, update it after every instruction, and check for differences.
 Advantages:
  * Easy to implement
  * We'd really catch *every* memory write...
 Disadvantages:
  * ... but *only* memory writes, obviously.
  * This would only ever pause execution *after* the instruction which hit the breakpoint. Pretty annoying, even moreso because viewasm can't scroll above CS:IP at this point

2) Tie the lowest-level memory access functions directly to the breakpoint module, and evaluate breakpoints on every function call.
 Advantages:
  * We'd really catch *every* memory read and write call
 Disadvantages:
  * Still only ever pauses execution *after* the instruction which hit the breakpoint.

3) Tie unasm() to the CPU state. We can then calculate the memory address affected by an instruction.
 Advantages:
  * Fairly clean and painless implementation.
  * Adding more detailed information to the UNASM structure, we leave room for a future expansion of viewasm.
 Disadvantages:
  * Calculation needs to be coded separately for every type of instruction (see generic/unasmdef.tbl). Thus, there may be certain edge cases in the current state where we don't catch a memory read or modification.
    To simplify the discovery of these edge cases, I've implemented method 1) as well, which is used in Debug builds
  * Now, every instruction needs to be disassembled separately before executing it. Has a heavy impact on speed in Debug mode as soon as we have just one breakpoint...

Other features in this commit:
------------------------------
* Make viewasm's view->cursor absolute as well. Fixes the status bar and reduces confusion.
* When switching the debug utility to Unassemble mode, always scroll to CS:IP. Believe me, you do want this.
Display a status message in every debug window when a breakpoint is hit
Use 32-bit segment and offset variables in Ctrl-G
Fix activity of Debug menu items
Ignore memory breakpoint prediction for LEA and LES