Work with current aenum version

[perey]

Pegl uses aenum for its extensible enums, which are used to support different EGL versions and extensions that add new values to existing enumerations.

Code and tests were generally written for aenum 2.2.6, but Pegl is no longer pinned to this version as of d3c6eff. That commit also fixed one resulting bug, but another issue has arisen and others may yet arise.

Current aenum versions (namely 3.1.8) will no longer accept unknown values when constructing an IntFlag instance from an int. Trying to do so doesn't give an error, but returns the int itself. I don't know if this is an intended behaviour change or not.

Before:

>>> class TestFlag(aenum.IntFlag):
...     NONE = 0
...     BIT_0 = 1
...     BIT_1 = 2
...
>>> TestFlag(3)
<TestFlag.BIT_1|BIT_0: 3>
>>> TestFlag(8)
<TestFlag.8: 8>
>>> TestFlag(10)
<TestFlag.8|BIT_1: 10>

After:

>>> class TestFlag(aenum.IntFlag):
...     NONE = 0
...     BIT_0 = 1
...     BIT_1 = 2
...
>>> TestFlag(3)
<TestFlag.BIT_0|BIT_1: 3>
>>> TestFlag(8)
8
>>> TestFlag(10)
10

The difference currently causes problems in tests that load an EGL version lower than the native library actually supports. As a result, enums like ClientAPIFlag aren't extended with newer options... but the library can still use them in values that it returns. This causes tests to fail when they expect a value to be an instance of the enum, but they receive a plain int.

Options:

1. Be prepared to deal with a plain int. This would affect both tests and user code, and probably means giving up some advantages of enums (like "in" testing for flags).
2. Add all known flags to all enums regardless of which version is actually loaded. This won't solve the problem for unknown extensions, though.
3. Define placeholder flags for unused bits on flag enums. Later EGL versions and extensions then add aliases for them.
4. Report an issue on aenum and hope its behaviour will change back.
5. Stop depending on aenum and make my own extensible enums.

Of these, option 3 seems like the most practical.

[perey]

Two problems with option 3: it doesn't solve the issue for non-flag enums where unknown values might be passed back from the native library, and it pollutes the namespace of all enums, possibly making the default name for a flag something generic like BIT_2 instead of WINDOW_BIT.