Added Conditional Breakpoint Support

[3rdit]

PR Overview

This PR adds conditional breakpoint support to the debugger, allowing a user to specify expressions that must evaluate to true for the breakpoint to actually trigger. This is implemented at the debugger core level (not adapter level), so it works the same across all adapters.

As discussed with @xusheng6:

The conditions for breakpoints are written using the expression parser (i.e. $rax == 0) making it the exact same for each debugger. The API now has:

• C++: SetBreakpointCondition(), GetBreakpointCondition() on DebuggerController
• Python: set_breakpoint_condition(), get_breakpoint_condition()

For example:

controller->SetBreakpointCondition(address, "$rax == 0");
std::string cond = controller->GetBreakpointCondition(address);

controller.set_breakpoint_condition(addr, "$rbx > 100")
cond = controller.get_breakpoint_condition(addr)

In the breakpoint widget, there's a new "Condition" column that can be set by right-clicking and pressing "Edit Condition...", this works in the widget and disassembly view.

The condition is also persistent across sessions (saved to the binary view metadata).

Upcoming Changes

• Condition validation on the input dialog; the idea being to stop users from entering invalid expressions
• Possibility of adding hit counts, e.g., break after N hits
• Include the condition string in condition-changed event payloads (AbsoluteBreakpointConditionChangedEvent, RelativeBreakpointConditionChangedEvent) so subscribers don't need a separate API call to retrieve it.
• It makes sense to have some sort of unit testing for this. I reviewed the unit testing and noticed how breakpoints get tested in debugger_test.py, it would be trivial to add a quick unit test for conditions.
• Adding callbacks for conditional breakpoints being hit (Support callback when a breakpoint is hit #422). That may be out of scope for this PR albeit and @xusheng6 will need to advise.

This PR will close #93 and maybe close #422 (if the feature above is approved to be added in this PR).

[xusheng6]

Hi @3rdit I will review this ASAP and let you know what I think

For context, I am working on a different PR that adds hardware breakpoint #53. And in light of the hardware breakpoint, I plan to make another large refactor on the breakpoint handling, e.g., the added breakpoints will be referred to by their index, not their address, etc.

This would mean some non-trivial merge conflict in the future. However, I hope to minimize the frictions for you as you are doing these all for free. I will most likely review and merge your PR first, and brace for the merge conflicts on my branch. Hopefully that will be manageable