Add NS_ENUM support, for Swift

[cormacrelf]

See NS_ENUM docs. See this excerpt from docs.md for motivation:

Normally, the ergonomics of C enums in Swift is very poor; you can't use the variants directly and pass them to function accepting the typedef name, because Swift sees the variants each as just raw integers and the typedef name as a newtype. So you essentially have to redefine the enum in Swift, get its .rawValue and convert it to the C enum type, and convert back in the other direction.

With NS_ENUM/CF_ENUM, you can import e.g. #[repr(i32)] pub enum A { Abc, Def } in Swift and use it as A.abc as you would with a Swift enum.

Config is like so:

sys_includes = ["CoreFoundation/CoreFoundation.h"]
[enum]
swift_enum_macro = "CF_ENUM"

Output is like so:

typedef CF_ENUM(uint64_t, A) {
  a1 = 0,
  a2 = 2,
  a3,
  a4 = 5,
};

It clobbers cpp_compat's effect on enums, which is normally to add a C++11 fixed type in an ifdef (enum Name: uint32_t { ... }). This is because CF_ENUM/NS_ENUM will already do that; the difference is it works in Objective-C as well, and maybe they do some other annotation magic to get Swift to recognise enums.

Edit: I'll fix clippy later and also there's a failing test (test_body) but I think that was present before I made the changes so I'll check that too.

[cormacrelf]

@emilio I think all the issues are resolved, thanks for the reviews, please have another look when you have a chance :)

[emilio]

I believe this is not what you intended. This is effectively self.repr.ty.is_some() so it should be simplified to that probably.

[emilio]

To be clear, I wasn't particularly against the annotation (though it probably isn't terribly useful and we can add it back if ever needed). I just thought that storing the "resolved" value shouldn't be necessary, since we store the annotations already.