feat!: Make the core crate no-std

[mwcampbell]

This is a prerequisite for eventually implementing accessibility for toolkits in embedded environments, such as those supported by Slint. And I don't think it's too drastic a change for the potential benefits.

The next step is to make accesskit_consumer no-std. That depends on estokes/immutable-chunkmap#10.

It's a breaking change because I had to drop the Affine::rotate method, which depends on a math function that's not in core. I don't think that's really a problem; I've never used that method. And anyway, this is more of a feature than a fix. And I have more breaking changes planned for this next release cycle.

This also adds the usual dummy changes to force the proper version number bump for the downstream crates.

[kpreid]

It's a breaking change because I had to drop the Affine::rotate method, which depends on a math function that's not in core.

FYI, most such functions including this one can be obtained from libm, which contains pure Rust code implementations of standard float functions. libm can also be used indirectly through the num_traits::Float trait (with the libm feature enabled) to “polyfill” the missing std methods. I don’t mean that you should bother doing this; just that avoiding all trigonometry is not a prerequisite for adding no_std compatibility.

[DataTriny]

You didn't mention how you tested this, so here's how I checked that it indeed compiles, for reference:

cargo build -p accesskit --target thumbv7em-none-eabihf

[mwcampbell]

@kpreid Well, I've also set the expectation of zero dependencies with default features, so I don't think adding libm is an option. I think it's simpler to just drop the rorate method, since in an accessibility context, it's probably not going to be used.

[mwcampbell]

@DataTriny I didn't think to try compiling for another target, so thanks for that. I knew that just adding the no_std module-level attribute would take the std crate out of scope, which should catch most if not all problems.

[DataTriny]

I think it's simpler to just drop the rorate method, since in an accessibility context, it's probably not going to be used.

Actually I think it is the case for many other methods in the geometry module, at least in a full Rust environment. I wonder if we should just keep the types and generic constructor methods at some point (moving the methods we need in the consumer crate obviously).