Support rkyv

[KodrAus]

From #310

Add an rkyv unstable Cargo feature that derives #[rkyv::{Serialize, Deserialize}] on the inner flags type so that end-users can then derive rkyv traits on the public one.

Since rkyv is still unstable, we should come up with some scheme that lets us continue to upgrade the dependency while it remains unstable without needing to bump the major version of bitflags itself. It wouldn't be such a big deal to bump bitflags if we don't make breaking changes to the BitFlags trait, since we can re-export its public API, but should consider other options first so that we don't end up needing to bump it too regularly for unstable dependencies.

[MarijnS95]

Note that we might also need bytecheck for rkyv support.

[MarijnS95]

Since rkyv is still unstable, we should come up with some scheme that lets us continue to upgrade the dependency while it remains unstable without needing to bump the major version of bitflags itself. It wouldn't be such a big deal to bump bitflags if we don't make breaking changes to the BitFlags trait, since we can re-export its public API, but should consider other options first so that we don't end up needing to bump it too regularly for unstable dependencies.

Something like nalgebra does for glam, by depending on multiple versions selected with feature flags?
https://github.com/dimforge/nalgebra/blob/4a5183ae590ba17a28803480b911eabb1690f461/Cargo.toml#L41-L50

[KodrAus]

I've opened #329 to come up with a policy for supporting unstable features. Any feedback there would be greatly appreciated!

[KodrAus]

I think we'll end up supporting rkyv through #348 (comment) rather than directly. That design is still shaking out a bit, but should let you add custom derives to your flags types without losing the codegen experience.

[KodrAus]

Now that #348 is merged I think we can close this one, we won't need to add direct support in bitflags for you to use generated flags types with rkyv.