Undo workarounds for Xcode 16.3 typed throw crashes

[lawrence-forooghian]

Once swiftlang/swift#80746 is merged, install the nightly toolchain and check whether our codebase compiles after reverting the workarounds introduced in #268. Then once Xcode 16.4 is released we can decide whether we want to revert the workarounds and just say "we don't support Xcode 16.3 because it's broken".

┆Issue is synchronized with this Jira Task by Unito

[lawrence-forooghian]

The commit message of 10d8f79 incorrectly stated that it resolves this issue; reopening.

[lawrence-forooghian]

Looks like swiftlang/swift#80746 didn't make it into the Swift 6.1.2 release branch, so I guess it's not in Xcode 16.4.

[lawrence-forooghian]

Given that we would like this to be throws (ARTErrorInfo) where possible in our v1 release (to avoid having to make a breaking change later), and that we want to do a v1 release before Xcode 26 is released in September, I'd suggest the following:

• introduce conditional compilation based on whether Xcode 26 or later is being used (i.e. #if swift(>=6.2)), and if it is then use the pre-[ECO-5294] Work around Xcode 16.3 compiler crashes #268 signatures for those methods
• add a CI job to test on Xcode 26 beta

(This means that a user may get a broken compilation when they upgrade to Xcode 26, but I don't think we need to consider that to be a breaking change on our part.)