Make Debug fancy again and handle #[cfg] properly.

[chris-morgan]

Debug was implemented using the nice readable flag names in #7, but the flag names were removed in #9 because it used $Flags which broke trivial #[cfg]-based removal of flags. Changing .contains($Flag) to .contains($BitFlags { bits: $value }) instead (akin to what .all() did) would have fixed that issue, allowing a friendly Debug again, but then I found a further improvement to make, because the #[cfg] behaviour was still off, as a flag’s value was still written out regardless of the #[cfg] attribute, so if it contained stuff that didn’t exist bitflags! would still blow up. This is inconsistent with how such things work in Rust proper, so I’ve fixed it.

The fix is rather convoluted, involving a dummy module, a bunch of dummy constants, a nested function and glob imports, but it works, avoiding referring to $value successfully. This change causes this to work:

bitflags! {
    flags Foo: u32 {
        #[cfg(a)]
        const A = 0b1,
        #[cfg(a)]
        const B = A.bits,  // or anything else that is `#[cfg(a)]`
    }
}

(Formerly all() was still trying to use A.bits when cfg(not(a)) and thus A wasn’t defined.)

This change allows #[cfg] on a flag to work like it should, allowing it to depend on things that don’t exist unless the conditions are met. Sure, that seems a pretty rare case for flags, but it’s real. Beyond the style of example above, my imagined scenario is a -sys crate having declared certain flag values, but only when certain features are enabled, and so when defining the bitflags in another crate (for the -sys crate doesn’t use bitflags) you can only use those values with the appropriate features.

[alexcrichton]

Thanks!