Description

This change is a proof of concept implementation that allows C++ enums to be exposed as enum.Enum objects on the Python side. I've decided to make this change partly to spark a design discussion about what would make the most sense when trying to expose C++ enums as standard library enums.

• Should this functionality exist using a new class (as done here) or should we try to make it work with enum_? This implementation uses a new object type stdlib_enum. Personally the backwards compatibility problems seem complex enough that making a new enum type is worthwhile, but there's a tradeoff of increased binary size. I think we would want to phase out the old enum class in favour of this new one.
• Should you be able to add methods to enums? This one does not, but it's inflexible as a result.
• Should you be allowed to select the type of enum to create (Enum, IntEnum, IntFlag)? If so, how? An optional argument to the constructor seems like the obvious choice.
• What should the interface for creating these classes look like? Does using a destructor make sense as implemented here, does a finalize() method make more sense? How should that interact with being able to add methods (if at all)?
• Does an optional include (as done here) make sense or should this be integrated into pybind properly?

TODO: Properly implement name().

Currently there are no docs or tests because the design might change a lot.

Kudos to @aldanor who's design I started from.

Implemented #530

Suggested changelog entry:

TODO upon design decisions