Remove default dependency on bitvec

[djc]

The bitvec crate does not appear to be fundamental to nom, yet it's enabled by default. It also brings in several rarely-used dependencies on its own (funty, radium, tap, wyz). Even if I disable default features, I cannot currently reenable std features without also enabling the bitvec feature (hopefully weak feature deps are coming soon). In the meantime, I think it would be better if default, alloc and std did not enable bitvec by default -- instead we could provide a separate bitvec feature and potentially bitvec-alloc/bitvec-std flags (or just leave those to downstream crates to manage).

Unfortunately I suppose this would be a semver-breaking change, but given the breakage today due to bitvec dependencies, it would maybe be nice to get this done sooner rather than later.

[djc]

(I'm happy to do the legwork on this if we're aligned on the goals/timeline.)

[Geal]

there's no defined timeline for the next major version of nom, but I'd be happy to see a better way around cargo features. I'll check if there's other breaking changes I need to pass at the same time

[tweksteen]

FYI, this issue is also relevant for Android (AOSP). We try to minimize the number of crates we rely on and therefore carefully enable features to limit new dependencies. We have imported Dirkjan's patch, until the next release of nom occurs.

[Geal]

bitvec input types are now in the nom-bitvec crate, since the release of nom 7: https://crates.io/crates/nom/7.0.0