Optionally implement bytemuck::Zeroable, for safe zero-allocation

[eira-fransham]

Closes #286.

We only use derive(Zeroable) in one place, as the atomic integer types don't implement bytemuck::Zeroable at time of writing. This appears to be an oversight in bytemuck.

The Zeroable trait only specifies that the type can be created with an all-zeroes bit pattern, and so this cannot be abused to overwrite the locks with all-zeroes (although doing so would require &mut access anyway).

[Amanieu]

Do you think you could send a PR to bytemuck to support atomic types? That way we can just use #[derive(Zeroable)] everywhere.

[Amanieu]

Can you document the feature in README. It's a bit confusing that we have both bytemuck and bytemuck_traits features, but that's an unfortunate cargo limitation.

[bjorn3]

Having the feature called "bytemuck" works on nightly with -Znamespaced-features through bytemuck = ["dep:bytemuck", "lock-api/bytemuck"] I believe.

[nolanderc]

Zeroable has been implemented for Atomic* types in Lokathor/bytemuck#157