Update runtime defines to match Apple platforms

[triplef]

This updates the defines for YES, NO, nil, and Nil to match Apple platforms:

• Use objc_bool language keywords for YES and NO if available:

  Previously, the BOOL type was simply a typedef for signed char, and YES and NO were macros that expand to (BOOL)1 and (BOOL)0 respectively. To support @YES and @NO expressions, these macros are now defined using new language keywords in <objc/objc.h>: ... The compiler implicitly converts __objc_yes and __objc_no to (BOOL)1 and (BOOL)0. The keywords are used to disambiguate BOOL and integer literals.
  https://releases.llvm.org/3.1/tools/clang/docs/ObjectiveCLiterals.html

  In our experience using @YES and @NO works fine without this change, but maybe there are other benefits and it seems more correct to use these keywords when available.

• Define nil and Nil as NULL/nullptr without casting to id/Class.

  While these casts are certainly correct, they result in warnings like the following when using nil instead of NULL for by-reference variables (like for a returned NSError):

  warning: incompatible pointer types sending 'id' to parameter of type 'NSError __autoreleasing ' [-Wincompatible-pointer-types]

  While using NULL would be more correct here, we found that a lot of code uses nil parameters for these kinds of APIs, which in our case results in a lot of warning-noise in 3rd party code we are using, and because these warnings don’t appear on Apple platforms authors can be hesitant to fix these.

Apple’s implementation is e.g. available here for reference (__DARWIN_NULL is defined as NULL): https://opensource.apple.com/source/objc4/objc4-818.2/runtime/objc.h.auto.html

[davidchisnall]

Thanks. I don't like the changes to nil and Nil because those originally existed for explicit type checking that you really meant a null Objective-C object / class. ZipArchive/ZipArchive#573 is fixing a real bug according to the language spec, just not a high impact one. Apple eventually gave up trying to get people to fix these bugs defined these both to NULL because otherwise people turned off compiler warnings. Unfortunately we probably have to do the same thing. It would be nice if we could have the old definitions guarded on something like #ifdef I_KNOW_THE_DIFFERENCE_BETWEEN_AN_OBJECT_POINTER_AND_A_C_POINTER but it's probably 20 years too late.

[triplef]

Yeah totally agree...