ares_status_t enum for status codes

[bradh352]

The list of possible error codes in c-ares was a #define list. This not only doesn't provide for any sort of type safety but it also lacks clarification on what a function may return or what it takes, as an int could be an ares status, a boolean, or possibly even a length in the current code.

We are not changing any public APIs as though the C standard states the underlying size and type of an enum is int, there are compiler attributes to override this as well as compiler flags like -fshort-enums. GCC in particular is known to expand an enum's width based on the data values (e.g., it can emit a 64bit integer enum).

All internal usages should be changed by this PR, but of course, there may be some I missed.

Fix By: Brad House (@bradh352)

[gvanem]

What about ares_set_sortlist()etc.? Still many hits for int ares_.

[bradh352]

What about ares_set_sortlist()etc.? Still many hits for int ares_.

I have intentionally not changed any public API interfaces as it could break ABI compatibility. Compilers aren't guaranteed to internally use int for an enum, especially if someone is compiling their code using GCC and are specifying -fshort-enums.

non-public hits for int ares_* might be addressed by #570 ... as I think I got all of them that don't return weird codes like -1, 0, 1.