Raymond, thanks for your support.

I am happy to have a flags variant.  The advice to wait and let Enum mature instead of adding the Flag variant at the beginning was sound, and we have a better product to show for it now.

The four base Enum-type classes will be:
- Enum
- IntEnum
- Flags
- IntFlags

I see no reason to add any more than these four to the stdlib -- further specializations can live in recipes, third-party modules, or private libraries.

While Enum and Flags are the heart of the enum module, IntEnum and IntFlags are present for two reasons:
- commonly needed when interfacing with other systems
- use in the stdlib itself

Pollution (otherwise known as enums escaping into other code where they don't make sense) is controlled by:
- IntEnums losing their enum status as soon as they are combined with
  any other number; and
- IntFlags losing their enum status as soon as a non-bitwise operator is
  used on them.

I'll commit as soon as the test suite is finished (and any failures are not attributable to these changes), and work on the docs later.

Serhiy, I'm not going to include your changes to re, os, etc., as they are not part of adding Flags/IntFlags.  Please open new issues for them.  I am not opposed to those changes, as

>>> re.I
<Flags.IGNORECASE: 2>

is more useful than

>>> re.I
2