Replace objc with objc2

[madsmtm]

Redo of #513, see that for previous discussion and motivation (GitHub Actions was giving me trouble).

---

I've focused on making this PR as minimal as possible, that is, I'm explicitly not trying to actually use any of the new features that objc2 offers - we can discuss those separately as we get there. So as-is, this PR is only a small improvement on the status quo, though still definitely an improvement.

The main difference you have to know for now is that all arguments and return types must implement a specific marker trait objc2::encode::Encode, which makes it possible to catch type mistakes at runtime, when debug assertions are enabled (e.g. cases of passing an u32 where an isize was expected). This is a huge boon to soundness, and the few mistakes I've found and corrected are likely only the tip of the iceberg - I could use someone's help to run this on bigger code-bases that exercise more of cocoa/cocoa-foundation.

Feel free to ask any questions about anything!

CC recent contributors @jrmuizel, @mukilan, @jdm and @michaelwright235.

[madsmtm]

(That the semver checks are failing is expected, this is a breaking change).

[nicoburns]

@madsmtm Do you have a read on how this crate differs from the relevant higher-level crates in the objc2 family? (are there equivalent crate(s)). Would it make sense to look at more heavily adopting some of those crates? Or even outright replacing (some of?) the crates in this repo with ones from https://github.com/madsmtm/objc2 ?

[madsmtm]

Do you have a read on how this crate differs from the relevant higher-level crates in the objc2 family? (are there equivalent crate(s)). Would it make sense to look at more heavily adopting some of those crates? Or even outright replacing (some of?) the crates in this repo with ones from https://github.com/madsmtm/objc2 ?

There's some fairly old discussion of a few lower-level details in #513, but yeah, nowadays we have objc2-foundation, objc2-app-kit and objc2-quartz-core, which completely replace the functionality in cocoa, along with providing:

• Actual type safety (everything isn't just an id pointer)
• Proper memory management (no longer need to do retain/release calls, autorelease pools aren't as important)
• Automatically generated bindings to almost everything in those frameworks

[nicoburns]

A couple of followup questions:

• Does this extra type safety and generated bindings have compile time and/or code size implications?

• Are there bindings for CoreText somewhere in the objc2 family of crates? Those seem to be a heavily used part of this repo, but I couldn't find them for objc2. And if not, are there other frameworks for which bindings are currently missing?

[madsmtm]

Does this extra type safety and generated bindings have compile time and/or code size implications?

They do have a compile-time cost, but it's quite low by now if you only enable the features you need, see the docs.

Wrt. code-size, as long as you use LTO, there shouldn't be a difference. I'm considering adding #[inline] to ensure that this happens without, but I'm slightly unsure of the compile-time cost of doing so, so haven't done it yet.

Are there bindings for CoreText somewhere in the objc2 family of crates? Those seem to be a heavily used part of this repo, but I couldn't find them for objc2. And if not, are there other frameworks for which bindings are currently missing?

CoreText is in the category of a CoreFoundation-like framework, these aren't supported yet because they don't actually use Objective-C, and the memory management scheme is completely different, see madsmtm/objc2#556.