New versions

[madsmtm]

• [x] The branch is named new-versions, such that the full CI will run.
• [x] Changelogs have only been modified under the Unreleased header.
• [x] Version numbers are bumped in the following order:
  • ~objc2-proc-macros~
  • objc-sys
  • objc2-encode
  • objc2
  • block2
  • Framework crates (not modified in this PR, set to v0.2.0 in https://github.com/madsmtm/objc2/pull/592).
• Local tests have been run (see helper-scripts/test-local.fish):
  • [x] macOS 10.14.6 32bit
  • [x] iOS 9.3.6, 1st generation iPad Mini

Post merge:

• [x] Crates are published using cargo publish (or maybe cargo release?)
• [x] A tag is created on the merge commit for each new version.
• [x] icrate v0.1.1 is published, deprecating the crate and linking to the new alternatives.

[madsmtm]

why do the framework-crates don't use objc2 or block2 as a workspace dependency? There's probably a good reason but figured I'd ask.

Because I found that since I autogenerate the Cargo.tomls, it wasn't really a maintenance restriction, and then I might as well maintain a MSRV of 1.60 for at least a little while yet. Will do it as part of https://github.com/madsmtm/objc2/pull/577.

[madsmtm]

Update: I'm hitting crates.io's rate-limits for publishing new crates, it's gonna take me a while to get all of these out. I've sent an email to the crates.io team and requested an increase, so that it doesn't happen again.

Additionally, I ended up publishing icrate v0.1.2, as both v0.1.0 and v0.1.1 stops compiling with the newer objc2 v0.5.1, since they used glob imports, and I added the NSObjectProtocol::hash method. I considered yanking objc2, but decided to go this route instead since I caught and fixed the problem within ~2.5 hours, and it's only if someone happened to run cargo update in that time-frame that their build would be broken (and the fix for users would be cargo update no matter which path I took to fix it).

Will add you (@simlay) as co-owner once everything is published.