fix: Bump objc2 to 0.5.0; bring icrate 0.1.0

[DataTriny]

Replaces #200

• Split icrate into multiple crates madsmtm/objc2#537,

• Update objc2 and icrate versions rust-windowing/winit#3256

• Update to latest objc2,

• Introduce icrate as a dependency,

• Remove handmade AppKit types in favor of auto-generated ones provided by icrate,

• Use type aliases from icrate as much as possible

The compile time of accesskit_macos increases a bit due to icrate. This shouldn't be a big issue for Rust users who will probably have it in their dependency chain already. Bindings generation will be slightly slower, but I don't think this should be a concern.

[DataTriny]

icrate 0.1.0 has been released, although the path towards reducing the number of features isn't clear at the moment. I currently don't have access to my Mac, I'll come back to this next year anyway.

[DataTriny]

I think we use some methods that might not need to be marked unsafe:

• NSView::convertRect_toView,
• NSView::isFlipped,
• NsWindow::convertPointFromScreen,
• NSWindow::convertRectToScreen

Otherwise this PR is ready for review.

[mwcampbell]

I see several places where we use Id::cast1 in an unsafe block to cast from a specific type to an NSObject or AnyObject. I wonder if there's a safer way to do this. I'd also like clarification from @madsmtm on when to use NSObject versus AnyObject.

[DataTriny]

The safe alternative to Id::cast in this context is Id::into_super, but then we have to call it multiple times to go up the inheritance chain.

I think the only place where we have both an NSObject and an AnyObject is in PlatformNode::parent. Since we get an AnyObject from NSView::accessibilityParent, and since I don't think it is possible to transform it into an NSObject, I don't think we have much choice here.

[mwcampbell]

I'd rather call Id::into_super multiple times to reduce use of unsafe.

[madsmtm]

I think we use some methods that might not need to be marked unsafe:

I think I'm considering a way to automatically mark simple things like this as safe, but it's a difficult trade-off between usability and soundness.

I've opened madsmtm/objc2#549 for the specific ones you listed, at least.

Id::into_super, but then we have to call it multiple times to go up the inheritance chain.

Tracking the more generic way in madsmtm/objc2#518.

I agree with calling into_super multiple times for now, even though it's quite verbose.

when to use NSObject versus AnyObject.

NSObject is the root class of almost all classes, but in theory a user could use a subclass of NSProxy, or they could define their own root class. So in those cases, where we don't know anything about the object, we use AnyObject.

If you can use NSObject, then you should. But if a protocol you're implementing takes &AnyObject, or something returns Id<AnyObject>, then you must use that (and you'll have to live with the limited functionality).

[mwcampbell]

@DataTriny I'd like to replace Id::cast with Id::into_super (making multiple calls as necessary). This PR also needs to be brought up to date with the role description support we just merged. Once those fixes are done, I'm ready to merge this, and we can release everything we have pending, including the Python bindings.

[DataTriny]

Yup! Will do this tomorrow though.

[mwcampbell]

@DataTriny Would you mind if I do these fixes and then merge this PR? That's one advantage of us both working in the upstream repo.

[DataTriny]

Of course, go ahead!