Make a nice Debug impl for each bitflags.

`Debug` was implemented using the nice readable flag names in bitflags#7, but
the flag names were removed in bitflags#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:

```rust
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.