Disable STRIP_INSTALLED_PRODUCT at least for libBlocksKit target

[CFKevinRef]

STRIP_INSTALLED_PRODUCT aka "Strip Linked Product" in the Build Settings section of the project file should be disabled at least for the static library target. The stripping should probably be left up to whatever wants to eventually link to the library.

Related: Link Time Optimization and Issue #108

In issue #108 there is a warning when linking libBlocksKit.a. This appears to show up when the final product is not using LTO. Since libBlocksKit was built with LTO enabled, the library is full of LLVM bitcode awaiting a final optimization step instead of native object files. Having those bitcode files show up during a non-LTO linking step seems to throw that warning but otherwise have no ill effects.

On the other hand, if that final product does have LTO enabled, the stripped version of libBlocksKit doesn't contain sufficient symbols to complete the optimized linking step. I believe this is because the bitcode intermediates still need that information to successfully apply LTO when generating the final binary.

We were in the second scenario there, and getting these errors:

Undefined symbols for architecture armv7:
  "_ffi_closure_inner", referenced from:
      _ffi_closure_SYSV in libBlocksKit.a(sysv.o)
  "_ffi_prep_args_SYSV", referenced from:
      _ffi_call_SYSV in libBlocksKit.a(sysv.o)
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Undefined symbols for architecture armv7s:
  "_ffi_closure_inner", referenced from:
      _ffi_closure_SYSV in libBlocksKit.a(sysv.o)
  "_ffi_prep_args_SYSV", referenced from:
      _ffi_call_SYSV in libBlocksKit.a(sysv.o)
ld: symbol(s) not found for architecture armv7s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

otool -vS libBlocksKit gives pretty sparse output as well, with those symbols missing of course.

With STRIP_INSTALLED_PRODUCT disabled for libBlocksKit, the symbols show up in the otool output, and the optimized linking completed without error.

[zwaldowski]

Interesting find, that's what we'll probably do. Thanks.