Bitfield Integration in Structs

*Edits by maintainers:*

https://github.com/bitflags/bitflags/pull/326#discussion_r1179770888 suggests that there's no way to support zerocopy, but I think we can work around that.

*cc @KodrAus @qwandor*

IIUC, the problem is that:
- bitflags will need to have a `zerocopy_0_N` feature for each zerocopy 0.N version
- The emitted code will need to contain `#[cfg_attr(feature = "zerocopy_0_N", derive(...)]`
- These attributes will be emitted into the caller's crate, where `feature = "zerocopy_0_N"` isn't set, and so it won't have the intended behavior

However, I think we can work around this by instead modifying bitflags so that certain internals of its macros are gated by `#[cfg(feature = "zerocopy_0_N")]`. That way, the code emitted into the caller's crate will simply have `#[derive(...)]` attributes which are already correctly chosen.

The naive solution requires the caller to also depend on `zerocopy` so that derive-emitted code can refer to `zerocopy`. A more ergonomic solution depends on supporting a `#[zerocopy(crate = ...)]` attribute (#11) so that only bitflags needs to take a zerocopy dependency (which it then re-exports).

---

*Original text by @shilonic:*

I'm currently working on a project that requires integrating bitfields into structs while maintaining zero-copy functionality. I believe adding native support for bitfield fields would enhance the usability and flexibility of the zero-copy crate.
I have tried integrating the bitfield crate and modular-bitfield, but using these options requires two levels of validation:
* One to ensure the struct is correctly constructed from a zerocopy perspective.
* Another for validating the bitfields.

Questions:
What is the best way to integrate bitfields into structs using this crate?
Are there existing patterns or recommendations for handling bitfields efficiently in a zero-copy context?