Add support for Xcode Runtime issue breakpoints

[zenangst]

Short description 📝

This PR adds support for Xcode runtime issues breakpoints.
It simply adds a new case to the BreakpointExtensionID called .runtimeException which can be used to generate breakpoints.

Solution 📦

Add missing case to BreakpointExtensionID for generating runtime issue breakpoints.

Implementation 👩‍💻👨‍💻

• Adds new BreakpointExtensionID case to support runtime issue breakpoints
• Expands the XCBreakpointListTests to include looking for the runtime exception
• Update the breakpoints fixture to include a runtime issue breakpoint

[kwridan]

@all-contributors add @zenangst for code

[allcontributors]

@kwridan

I've put up a pull request to add @zenangst! 🎉

[zenangst]

Found a nasty little casing issue which caused the tests to not compile. Fixed here ad3d477

[zenangst]

I bit unsure what is going on with the test_read_write_produces_no_diff test.

[kwridan]

Thanks @zenangst

This is a good addition 👍 previously any breakpoints list with runtime exceptions within it would completely fail to parse.

One small suggestion / improvement for completeness, runtime exceptions have an associated type that is encoded within BreakpointContent for example:

<BreakpointProxy
   BreakpointExtensionID = "Xcode.Breakpoint.RuntimeIssueBreakpoint">
   <BreakpointContent
      uuid = "0E9F84AF-42FF-4236-B75A-97E449E6C66F"
      shouldBeEnabled = "Yes"
      ignoreCount = "0"
      continueAfterRunningActions = "No"
      breakpointStackSelectionBehavior = "1"
      type = "1">
   </BreakpointContent>
</BreakpointProxy>

From a quick trial, I've found the following:

• Thread Sanitizer: type = 1
• Undefined Behaviour: type = 2
• Main thread checker: type = 4
• System Frameworks: type = 8
• All - type = 65535

It appears to be a 16bit mask. It can be modelled as an option set. That said seeing it's only applicable to runtime exceptions it would mean it would be unused / optional for other types. I haven't quite figured out what a good public API for it would be. Perhaps can be done separately with some more thought put into it - mind raising an issue for it and if you have any ideas / suggestions?

Thanks again!

[zenangst]

@kwridan I tried something really quickly but I ended up with the clash between using CaseIterable and having an associated type on the enum. They don't really work well together.

I think to really nails this, I'll open an issue, so that the rest of the community can also chip in an spitball some ideas, like you suggested.

I pushed a commit to improve on the naming.

[zenangst]

Made an issue here - #763

[kwridan]

Awesome thanks @zenangst 🙏

[pepicrft]

Thanks for tackling this one @zenangst. I'll go ahead with merging this and I'll tackle your issue separately.