Breakpoint window

[Kingcom]

This adds a window for defining breakpoints, opened by clicking on the breakpoint button in the disassembly view.
The whole dialog content is evaluated, but a few things aren't loaded from or saved to breakpoints/memchecks yet because they have yet to be fully implemented there.

[unknownbrackets]

Cool.

For the things not loaded/saved, which do you need support for? I think it's not necessary to have multiple memchecks on the same start/end, or multiple breakpoints at the same address.

You can enable/disable breakpoints with ChangeBreakPoint(). ChangeMemCheck() can modify memchecks.

If they're editing from the list, might as well just use the initial values from the displayed memcheck/breakpoint vector. Otherwise, I guess it could have an accessor which takes references to get the current settings based on breakpoint address or memcheck start/end. To change a breakpoint address or memcheck start/end, just remove and re-add.

Note that the GetMemChecks() and GetBreakPoints() methods intentionally return a const vector, so modifying those structs will not change anything, only using the accessors will. This way CBreakPoints can maintain uniqueness and any other invariants we want to impose on it.

-[Unknown]

[Kingcom]

It's mostly minor stuff. I didn't want to mess with the breakpoint class in case you had something in the works for it.
The things are:
-Conditions. The expression parser still needs to be hooked into the breakpoint class. If we want to allow editing breakpoint conditions, it would also be handy to store a copy of the original expression string. Decomposing the postfix vector could be tricky
-there's no way to add a new breakpoint with the disabled flag yet. Though I could call ChangeBreakPoint() directly after adding.

I'll remove and later add breakpoints when editing them, though I'll add that functionality later on. The breakpoint window class has some code to change breakpoints, but it's not used yet. I'll probably need to redo the way I do it anyway.

[unknownbrackets]

For conditions, could just store the original string and the expression both in the BreakPointCond struct.

I tried to make all the changes necessary to easily hook it up, but let me know if anything else is needed (or just change it if you'd prefer.) I'm not currently planning any more changes. Edit: I take it back, except scheduling an invalidate via CoreTiming when a breakpoint is set during jit.

-[Unknown]

[Kingcom]

Alright, I'll do that tomorrow then.

[Kingcom]

Conditions work now.