Remove libstd from objc-sys and block-sys

[notgull]

This removes libstd as a dependency for objc-sys and block-sys, by replacing std::os::raw with core::ffi, which contains the necessary types.

This bumps to MSRV to at least 1.64, but it looks like this package doesn't have an MSRV policy yet (#203), so I hope that's not an issue.

[madsmtm]

Yeah, this crate doesn't have a policy yet so this wouldn't be a breaking change; however, I would still like it to work with winit, which is currently at 1.60.0 with a rough policy of "every Rust version released in the last 6 months".

[notgull]

We could use libc or cty to circumvent the MSRV bump, if you're fine with the extra dependency.

[madsmtm]

I think I've also sort-of tried to keep the amount of dependencies down.

For now, I've kinda deemed that the downsides of "bump Rust version" or "added dependency" outweigh the benefit "no_std support", since these are basically only useful on Apple platforms, where the standard library is already present.

But in a few months, when 1.64 is in winit's MSRV, I'll probably do this change.

[silvanshade]

But in a few months, when 1.64 is in winit's MSRV, I'll probably do this change.

One thing to note is that the Tauri project seems to want to keep an MSRV of 1.61. I'm not sure if I would let that be a deciding factor, just something to be aware of considering #174.

[notgull]

Whoops, I was deleting forks and I accidentally deleted the fork with this change.

Now that winit has an MSRV of 1.64, would this change be accepted now?

[madsmtm]

Yeah, I'd be fine with a MSRV bump, mostly because some things are much easier to express with GATs (from Rust 1.65).

Another thing that would be nice is more capabilities for const fn, esp. the fn pointer handling for eventually allowing safe method overriding in declare_class!. I'd also really like to start using ptr::cast_mut!

---

All in all we don't really gain that much from the bump yet though, since objc2 still needs std::sync::Once for declare_class!.
I think perhaps we could avoid that completely with a helper like objc2::__macro_helpers::CachedClass + (ab-)using the fact that the objc runtime is locked while creating classes? Or maybe we'd need to re-implement parts of std::sync::Once? Or perhaps do so using functionality from libdispatch?

Do you know what the recommended approach is for std::sync::Once-like functionality in no_std?

[madsmtm]

Please do roughly the same setup as I did in this PR to the url project (for both alloc and std, since neither are required).

[notgull]

Not as enthusiastic about this anymore.

[madsmtm]

No problem, I'll probably get around to doing it myself at some point, then I'll use the code here