Consider switching to bitflags

[lucab]

At some point in the future I will re-evaluate how we define Capability and CapsHashSet and possibly switch to use https://docs.rs/bitflags/latest/bitflags/index.html for those.

Unfortunately, we I started writing this library, the types generated by bitflags were not very ergonomic so it was better to go with a plain enum plus HashSet.

On the positive side, this will make the library a bit more lean, as flags manipulation will be done through integer arithmetic without allocating containers. However this is not really a pressing point, as capabilities introspection/manipulation is basically never done in any kind of hot-loop or sensitive spot.

On the negative side, this will require re-arranging most of the public interfaces and breaking the API. The latter cascades into all consumers of the library.

For these reasons I'm not currently going after this in the short term, but I'm leaving this open as a future working item.

[LeChatP]

One option is to keep the current public interface, mark it as deprecated, and create new ones using a different approach. This suppresses entirely the negative side. But also the different approach must be as simple as today.