Migrate away from bitflags

[sunfishcode]

Bitflags' from_bits_truncate does more than just mask off a fixed set of bits; it insists that all multi-bit flags be either completely present or completely absent. This makes it unsuitable for mask constants that include multiple bits where the individual bits may not all be defined yet but which may be defined in the future. And, bitflags' complement clears any unknown bits, breaking the a & !b idiom if there are any flags that are not defined yet but which may be defined in the future. In general, bitflags appears to be trying to be two things at once, sometimes appearing to enforce invariants about unknown or multiple-bit flags, but other times not.

Rustix's use of bitflags is to describe flags that are defined externally by the OS. New flags may defined that rustix doesn't yet know about, and rustix should preserve these flags. And OS's have their own conventions around multiple-bit flags which aren't always the same as what bitflags expects. Consequently, rustix would be better served by a bitflags alternative which doesn't attempt to (even incompletely) enforce any invariants about unknown flags or multiple-bit flags.

[sunfishcode]

With #787 we now use bitflags 2.4's const _ = !0 feature, which tells bitflags to treat all bits as "known" and avoid ever masking them out, so migrating off of bitflags is less urgent now.

[sunfishcode]

As noted above, this is less urgent now. Bitflags still appears to be by far the most popular flags utility library, so I think it makes sense to continue using it.