Issue #2678: forced zeroing weak references in public build.

[tomball]

Fixes issue #2678 by forcing zeroing weak references in public build, which matches the internal build.

[rluble]

Our internal build hits this error which this change.

[tomball]

That's good news, because j2objc users have been assuming zeroing weak references, like ARC has, since clang added the -fobjc-weak flag a couple of years ago. This pull request fixes several j2objc libraries which weren't building with them, because make/common.h added -fobjc-weak, but those libraries' makefiles redefined OBJCFLAGS using :=.

If something is broken internally, that means there's a similar problem where j2objc-including code isn't compiling with the -fobjc-weak flag (that's why I put in a #error in place of defining WEAK_ as __unsafe_unretained). __unsafe_unretained tells the compiler that the reference is unsafe when it's released, meaning messages can still be sent to the object's address in the now invalid heap area. It's a reference to a zombie object, and if the heap reuses that released memory first, a crash or a invalid memory overwrite happens. Crashes with zombies can happen more often in releases, because client systems often run apps with less memory than development and test environments use.

Zeroing weak references cause the address of the object to be changed to nil (zero) when it's released. Objective-C ignores all messages sent to a nil reference, avoiding those crashes or memory overwrites.

So we can remove the #error directive, but it will allow potential zombies into the code that isn't built with either ARC or the -fobjc-weak flag.