Remove `WindowBuilderExtIOS::with_root_view_class`

[madsmtm]

This was introduced in https://github.com/rust-windowing/winit/pull/609 (CC @mtak-), and while it makes sense, it feels quite unclean and inhibits other improvements (also, it is unsound, but that could be fixed by marking the function as unsafe).

Primary motivation is that it prevents us from doing the iOS equivalent of https://github.com/rust-windowing/winit/pull/2458, since objc2::declare_class! (intentionally) does not support dynamically declaring classes. If we want this, it should be done in a way that the desired superclass is known at compile-time.

I did a search on GitHub to get a feel for who was using it, seems like it's really only glutin, and that will have to do something else after https://github.com/rust-windowing/glutin/pull/1435 anyhow. Libraries like wgpu and vulkano-win have already found solutions for this, I strongly suspect that glutin could do something similar like (but I don't have a setup to verify that atm.):

let main_layer: Id<CALayer, Shared> = msg_send_id![view, layer];
let new_layer: Id<CALayer, Shared> = msg_send_id![CAEAGLLayer::class(), new];
let _: () = msg_send![main_layer, addSublayer: &*new_layer];

• [x] Tested on all platforms changed
• [x] Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• [x] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• [x] Created or updated an example program if it would help users understand this functionality
• [x] Updated feature matrix, if new features were added or implemented

Would like your input on this one @francesca64?

[francesca64]

@ArthurKValladares does brainstorm still use this?

[ArthurKValladares]

@ArthurKValladares does brainstorm still use this?

We do still use this internally. I can try to carve out some time early next week to explore the alternative solutions linked here used by wgpu and vulkano. We are also already on our own branch, with changes that don't really makes sense to be merged upstream, so I would not consider our internal usage of this feature to be a blocker for the PR.

[madsmtm]

Alternative solution would be to allow overriding the return value from +[UIView layerClass].

I'm going to merge this now, though if you find that none of the other solutions are workable, feel free to post an issue about it, then we can more easily discuss what to do.